[KDE/Mac] QStandardPaths possible solution

[David Faure]

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? 

Again, yes.

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 
purpose.

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
  -additional-data-dir -additional-config-dir
(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