[KDE/Mac] QStandardPaths possible solution

[René J.V. Bertin]

On Tuesday January 13 2015 20:40:05 David Faure wrote:

> On Sunday 11 January 2015 13:37:38 René J.V. Bertin wrote:
> > configure -prefix /opt/local/libexec/qt5 \
> 
> Well, this would break the suggested QStandardPaths patch quite a lot,
> that patch falls back to the Qt install prefix. Configured this way, it would 
> never find /opt/local as the place where apps put stuff.

Yes, as I said earlier, I realise that now. 

> That's why Tor Arne is right: it makes little sense to use the Qt install 
> prefix as the presumed root for where other libs and apps install their files. 
> These are two independent things.

So we come back to how it's done on Linux. How is /usr/share derived there in absence of env. variables?
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.

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

> 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? ;)

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

And just how do you think that would work out? Convince every author to change their code (or offload that burden onto the port maintainers), or make changes to Qt that provide the (platform dependent?) defaults for that new way of doing things? Which would take us right back to where we are now?
NB: I wouldn't be surprised if there isn't much in the current cmake and qmake build systems to put arbitrary resources at an arbitrary location in an app bundle, so we'd have to provide that logic too.

R.