[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[Ian Wadham]

Hi Jeremy, David and René,

On 04/01/2015, at 9:57 AM, Jeremy Whiting wrote:
> In trying this I think we have a couple of options as Rene pointed out.
> 
> 1. Support reading XDG_CONFIG_DIRS
> 2. Support some compiled in or runtime programatically added alternative path(s)
> 
> 1 would certainly be much faster and would fix the CI systems and building with kdesrc-build on mac (and a similar approach could be done on windows), but has the drawback of using environment variables, which would need to also be set by applications when launching them. This seems like a big drawback imo.
> 2 would take a bit of thought but would be more usable (think kde applications .app bundles that could be opened directly without setting any environment variables or other tricks) The problem with this approach is that it doesn't fix the CI system issue of needing to set custom data paths for unit tests.
> 
> Thoughts on these ideas? My plan at the end of december was to submit and revise Marko's patch which does similar to your patch david except that it does extract XDG_DATA_DIRS (and doesn't touch XDG_CONFIG_DIRS yet).

I have done a bit of digging around.

a) http://lxr.kde.org/ident?v=kf5-qt5&_i=QStandardPaths&_remember=1 already
    returns "3442 references in 857 files" to QStandardPaths.  More will be added...
b) References occur from all over Frameworks and KF5, not just GUI apps.
c) There should be a way to get a KDE app to recognise itself as a KDE app,
     by using a setting introduced via the Info.plist template [1].  Notably, there is
     supposed to be a LSEnvironment property via which you can set environment
     variables on a per-run basis [2].  But I have not been able to get this working
     yet (testing with qgetenv()).  OTOH you can define your own Custom Keys
     and values (see also [1]) and read their values via Objective-C code as in [3].
d) I have not tried this yet, but presumably qstandardpaths_mac.mm could test
     such a value, the first time it is called, to see if it has been called within a KDE
     app.  THEN QSP could set XDG_* environment variables, or whatever, if not
     already set externally.  Such a Custom Key could even have a value based
     on the MacPorts installation prefix (the one whose default is /opt/local).
e) Note that kdeinit4 and kded4 (and one or two others) are built as pseudo
     GUI apps on Apple OS X, because they may have to execute real GUI apps.
     So perhaps such apps could spread the word, via the Shell, to whatever
     non-GUI things they may start, such as kbuildsycoca or KIO processes.
f) I do not know how many other non-GUI apps there are in KF5 that use
     QStandardPaths.  If they are not started via kdeinit5 and friends, maybe they
     would need to be hand-coded to tell QStandardPaths to adopt XDG behaviour.
g) The LSEnvironment property is definitely NOT honoured if an Apple app's
     executable file is started from a command-line on Apple OS X.  That is in the
     documentation.  So maybe Custom Keys are the better way to go, using
     coding as in [3] below.  Then we could set XDG_* variables internally if
     they were not already set externally.

I think an Info.plist approach could support your alternative 2, Jeremy, and
indirectly your alternative 1.  Presumably CI could operate by pre-setting
XDG_* variables, as I think it does now.  Then QSP could skip setting them.

René has had direct experience with Info.plist files, so I expect he knows
how to get the above ideas to work in real code.

> On Sat, Jan 3, 2015 at 7:12 AM, René J.V. <rjvbertin at gmail.com> wrote:
> On Saturday January 03 2015 12:00:50 David Faure wrote:
> 
> > It's not Qt that puts stuff into ${prefix}/share and ${prefix}/etc/xdg,
> > it's the apps.
> 
> Hmm. So even if changing this kind of setting (adding paths to the front of a lookup list) in a new bit of code prepended to the standard Q(Core)Application initialisation routine, I'd personally still prefer to activate that selectively. Probably through a compile-time flag, to avoid having to change client code.
> 
> > > That'd work
> > > for the MacPorts install, but I'm not even sure if that'd be desirable for
> > > pure Qt5 applications installed through MacPorts ...
> >
> > I don't understand the distinction here.
> 
> There may not be a distinction if indeed the things being looked up depend on the application (and/or KF5) and not on Qt.
> 
> > Ian wrote:
> > > Perhaps there could be some way for an XDG-based program, from KDE or
> > > otherwise, to tell QStandardPaths to setXDGModeEnabled(bool xdgMode).
> 
> > Well, my initial suggestion was to add support for XDG_* env vars to QSP, we
> > could do that *without* a default value of /opt/local (unlike my current
> > patch), so that nothing happens unless these vars are set. It would do exactly
> > that - not affect non-MacPorts apps. This would indeed be "less intrusive".
> 
> Only if you can set those variables only for the applications that require them!
> 
> > But you guys said bad things about environment variables so I was trying to
> > look for other ideas :-)
> 
> Not bad, but rather sad ;)

It may be that the LSEnvironment property in Info.plist does not work any more
in the version of OS X I have (10.7.5 Lion), but it is odd that Apple's GarageBand,
iMovie and iTunes apps all have LSEnvironment values in their Info.plist files.
Otherwise I would not have tried using LSEnvironment.

What is the situation with those apps' Info.plists in Mavericks and Yosemite?

Cheers, Ian W.

[1] https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html#//apple_ref/doc/uid/TP40009254-SW1
And in KDE 4, we have some examples of prototype Info.plist files:
kde-runtime/Info.plist.template
kdelibs/kded/Info.plist.template
kdelibs/kinit/Info.plist.template
[2]
https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/TP40009250-SW1
See the descriptions of LSEnvironment.
[3]
http://iosdevelopertips.com/core-services/read-info-plist-key-value-pairs.html