[KDE/Mac] QStandardPaths possible solution
faure at kde.org
Wed Jan 14 08:36:31 UTC 2015
On Tuesday 13 January 2015 21:49:50 René J.V. Bertin wrote:
> So we come back to how it's done on Linux. How is /usr/share derived there
> in absence of env. variables?
It's the default value, as documented in the freedesktop standard.
> I think that it's the install prefix, or at
> least that's what it *could* be. When I look at the way configure is
> invoked for Ubuntu it's exactly the way I'm doing in the end (except for
> the exact path names of course)
> #> configure -prefix /usr -bindir=/usr/lib/x86_64_linux_gnu/bin #etc
> it's almost as if -prefix serves only to get the /usr/share path configured
Definitely not. You can install stuff into any other prefix, and as long as
you don't set XDG_DATA_DIRS, the default value for XDG_DATA_DIRS will still be
This is why you need to set env vars when installing things to custom
> > 1. The patch has a configurable default rather than using QLibraryInfo.
> > I'm
> > not sure how to add such a configurable value yet, but can figure it out
> > if we go this way.
> -xdgdatadir and -xdgconfigdir options? And if those are not given, your
> patch is not compiled in? That's what I have been suggesting!
It sounds weird to me as a developer, but I guess as a distributor/packager it
> > 3. The macports of qt5 patch qstandardpaths_mac.mm|cpp to support whatever
> > prefix they use as default with the XDG_*_DIRS support.
> Which is what we'll have to do for Qt 5.3 anyway, and probably Qt 5.4 too.
> In fact, it is already in place in the ports I've uploaded yesterday. Guess
> what I'd vote for if the current attempt or 1) fails? ;)
I guess this is indeed just a variant of option 1 in case option 1 is not
accepted. Still "at packaging time", just a bit harder (patch required).
> > 4. All applications/libraries that use QStandardPaths change to use some
> > "platform independent" way of finding their data files such as qrc
> > resource
> > files or installing files into each app bundle itself or something.
The use case for KF5 is libs, no app bundles involved at that point yet.
So yeah, maybe there are a few things that could go into qrc resources,
but going through all the uses of QStandardPaths to port them to that (for the
cases where it applies) sounds horrendous. It wouldn't fix the heart of the
problem anyway - we're not going to put the oxygen icon theme into a qrc...
[because huge, because no lib shipped with it, because we want to be able to
discover and load other icon themes, etc.]
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
More information about the kde-mac