[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Fwd: Qtbase patch for configurable standard paths
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2016-01-23 13:28:17
Message-ID: 25551188.EVdA3tAeuW () portia ! local
[Download RAW message or body]

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.
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]