On 2015-11-29 08:57, Cristian Oneț wrote:
Hi,I was just building some KDE apps (using frameworks) on OSX and encountered the same problem for which we (me and Patrick von Reth) created the QStandardPaths patch at Randa in 2014 [1]. The solution you propose in this mail requires all applications that were installing the rc file in '${KXMLGUI_INSTALL_DIR}/appname' to be changed to have the rc in a resource file and call setXMLFile on start. I'm not sure that all application developers will be aware that this change is necessary. Couldn't this be solved by the ECM module that provides KXMLGUI_INSTALL_DIR?
The KDEInstallDirs module literally just provides a standard set of variables for projects to use or not as they see fit. Given how it's used, it can't have any influence beyond that. ECM can't really help you with the setXMLFile call anyway (although maybe KXMLGui can be changed to always look in the resources as well as the QSP locations), but your options for the resource file are:
* explicitly change to using a resouce-based installation in each project * add an ECM command that generates the resource file for you, and add it to each project (probably no less work than the above)
* something horribly, horribly hacky
Another similar issue is the problem of setting 'NSHighResolutionCapable' to true in all gui applications. I see kate solves this by using a custom MacOSXBundleInfo.plist.in file but this approach is bad since again it requires all application developers to be aware of these platform specific issues. This should have been solved in ECM. Having all applications duplicate the same MacOSXBundleInfo.plist.in is the best way to make sure that some of the apps will fail to do it making them look blurry on highDPI and giving KDE applications a bad name this way.
The problem is that the opt-in nature of highDPI support is there for a reason - the application itself will probably need to do some work on this front to make it play nicely.
That said, ECM can probably help with the plist generation. We already have some minimal cross-platform setup stuff in ECMMarkNonGuiExecutable[0], although this doesn't even quite cover every gui vs non-gui option we want (there are things that need to be a GUI executable on Windows, but not a bundle on Mac, for example). Having an ECMCrossPlatformHelpers (or some such) module that deprecated ECMMarkNonGuiExecutable and did some other setup magic with plists etc could be useful. If anyone wants to gather requirements for it and put something together that would allow developers to specify some basic function information about a CMake executable target, go for it. I imagine this information would be like:
* is it a user-facing application or a helper executable for something else? (MACOS_BUNDLE vs not)
* does it have a GUI? (WIN32 vs not) * does it support highDPI? (generate some MacOSXBundleInfo.plist magic) [0]: http://api.kde.org/ecm/module/ECMMarkNonGuiExecutable.html _______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
