[KDE/Mac] QStandardPaths possible solution

[David Faure]

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

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.
This is why you need to set env vars when installing things to custom 
prefixes.

> > 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 
makes sense.

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