[KDE/Mac] Fwd: Qtbase patch for configurable standard paths

[René J.V. Bertin]

On Saturday January 23 2016 11:02:39 David Faure wrote:

I can live with a thread-safety restriction on the mode-switching method. That one is new and supposed to be called only under very specific conditions. Cases where the mode should be switched temporarily can now be handled with one of the new methods that provide a mode argument.

> > The patch is undoubtedly more complex than it could be ... and I don't really know what to thing of the intricate parent/child relationship between QStandardPaths and QExtStandardPaths =)
> 
> The split makes no sense, it should all be in QSP.

That would have obliged me to rebuild *everything* before I could even begin to test it, but that would also make it much less trivial to use a macro to get code to use the methods with an additional mode argument, no?
This is supposed to be a proof of concept implementation of my earlier KStandardPaths idea, i.e. one involving a wrapper class.
The methods with an additional argument could indeed go into QSP as protected or private methods, to be exposed via a friend class, but wouldn't that break ABI compatibility? That's the kind of detail I'm never certain about.

> But a patch like this is going to be hard to get into Qt, because it keeps attempting to say "XDG paths can make sense on all platforms".

Frankly, I don't see anything wrong with that, as long as there is indeed such an argument for some platforms, for a sufficiently large class of applications. 

What little feedback I've been getting on this topic from other MacPorts devs does indicate that MacPorts aim to let provided applications function as much as possible as they would in their environment of origin. For KF5 applications that would be how they function on a Linux desktop that doesn't run a full Plasma5 session. The easiest way to achieve that is to build and install them as much as possible as they are on Linux.

> I now think that the qt.conf idea is a much easier way to tweak QSP.

Patrick's argument for his patch is very similar to my argument why I'd prefer to have a different writableLocation. He appears to doubt though if qt.conf is the way to go for the complete use case, though. 

It is true that methods to add elements to the returned standardLocations *and* to specify alternate writableLocations would be more generic. While it appears to be true that qt.conf can contain groups, it is much less clear how that feature would could be used to allow different application and/or library groups/families that share an alternate QSP setting (notably the writableLocations). One would probably have to patch much more than just QSP, and probably deviate too much from what Qt considers the "normal" deployment usage on OS X. Also, what qt.conf documentation there is shows that it is rather clearly geared towards per-application settings on OS X. That makes it a good candidate for tweaking things in standalone app bundle builds (and then there'd be no need for supporting groups), but much less so for "desktop style" builds with a single shared Qt install.

A hybrid version could probably be implemented, where a (hypothetical) global qt.conf specifies the alternate paths and/or paths to add, and a runtime toggle switch determines what writableLocation returns. That would remove the need to defend XDG paths explicitly, but one would probably still use those XDG paths as an example to illustrate the possible uses of the patch.

R.