[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