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

David Faure faure at kde.org
Sun Jan 4 11:04:11 UTC 2015


On Saturday 03 January 2015 15:12:36 René J.V. Bertin 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.

A compile-time flag ... for Qt, or for apps?

For Qt would be a very bad idea, unless it's customary to install Qt twice on 
the system, once in a proper Mac OSX location and once in a MacPorts location?
If that's not how people do this, and a single Qt is used, then a compile-time 
flag for Qt can't work.

For apps ...well, I don't see how that flag would affect the behavior of 
QStandardPaths. Unless you add code to every app that uses a framework, but 
then it's about adding some code in main() (bad idea, not modular!), not a 
compile-time flag (-Dsomething).

> > 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!

I have to disagree with that "fear of breaking things by adding search paths".

For instance, on my system I have XDG_DATA_DIRS set globally to my own KDE 
install prefix (+ /usr/share of course). And yet I use apps that don't need 
this (firefox, skype, libreoffice, etc.). And what breaks? Nothing. They don't 
care for the extra lookup path, since they are looking for their own things, 
which are not in there anyway.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



More information about the kde-mac mailing list