[KDE/Mac] QStandardPaths possible solution
faure at kde.org
Thu Jan 15 07:09:19 UTC 2015
On Wednesday 14 January 2015 11:16:43 René J.V. Bertin wrote:
> On Wednesday January 14 2015 09:36:31 David Faure wrote:
> >It's the default value, as documented in the freedesktop standard.
> So it's probably hard-coded, but should be eligible to change somehow. I
> played with PC-BSD a while ago, and noticed it installs everything optional
> (w.r.t. its FreeBSD base?) in /usr/local , so it probably uses
> /usr/local/share. That's hard-coded too, apparently?
Yes, as I said, the default value is /usr/share:/usr/local/share.
> >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 /usr/share:/usr/local/share.
> That would be OK for "simple users" who install a private copy of Qt, but
> does the FreeDesktop standard really impose /usr or /usr/local on
> distribution systems?
Well, it doesn't "impose" it, it defaults to it. If you want to use something
else, you set XDG_DATA_DIRS.
> Even if it does, is Qt obliged to follow that dogma
> on a platform where the standard doesn't otherwise apply?
Well, not necessarily, no. But I thought it would make things easier, by using
the same env vars on both systems. We could go for $QT_DATA_DIRS, but what
would that gain? I don't see much point in that, other than not being able to
share scripts and tools between both OSes.
One example: update-mime-database from freedesktop.org. It will always use
$XDG_DATA_DIRS, not $QT_DATA_DIRS....
> >> -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 makes sense.
> Well, that's the point, right? As a developer I wouldn't bother getting this
> changed upstream as long as I can patch the code I deploy ;)
Developers don't want to keep local patches, but rather to set a development
environment that doesn't require that. Env vars are perfect for such a
So OK, I have no objection to a compile-time hardcoded prefix.
*That* on the other hand, doesn't have to be called xdg, since it's quite
unrelated to xdg. So maybe
(just -datadir already exists and means "where will Qt install stuff",
while -additional-data-dir would mean "where Qt also looks for stuff")
And it's additional to /Library or whereever QSP searches already.
This means binaries that have to be installed into a specific location, then.
If that works for you, good. I know that unfortunately it won't work on
Windows, too bad (same problem there, but a distributor can't know in advance
in which dir the user will install Qt) :(
> >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.]
> Hey, wasn't it your idea? :)
Definitely not. I mentionned it for single files looked up by a framework.
But it's definitely not a solution for entire icon themes.
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
More information about the kde-mac