KXmlGui Patched for Deployment

[Alex Merry]

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