[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

Hi René,

On 03/03/2015, at 9:38 PM, René J.V. Bertin wrote:
> On Tuesday March 03 2015 17:09:21 Ian Wadham wrote:
>> That looks as though it would work fine, but I still do not like that the choice of
>> policy for standard paths is part of building Qt 5.  I would like to be working
>> towards having one and only one one copy of Qt 5 in one Apple OS X system.
> 
> I don't think you can get around some form of choice when building Qt. Not if you want to be able to use a single Qt install for all possible use cases.
> In that case the code has to support all QSP policies, and then there are 3 choices one can make (given 2 policies):
> 1) default to policy 1 (stock)
> 2) default to policy 2 ("linuxy")
> 3) default to raising an error if the client application/code doesn't specify a choice
> 
> I think we don't want option 3, and if we accept the fact that despite the size of the K ecosystem it will probably remain a niche case on OS X we'll end up with hard-wiring a default choice to Qt's stock policy.

No, you could do it roughly as was done in Qt 4 for choosing a graphics-engine.  Build
Qt to use policy 1 (stock).  Use an environment variable or an Oswald type function to
select policy 2 "from outside Qt", when your program is running, only in cases where you
want policy 2.  If the env var is empty or the Oswald type function is not called, QSP would
simply stay on policy 1.

The Stefan trick could be used to ensure that the QSP policy is changed before main()
executes and before QSP can be used to find a path.  Thus the policy change could
apply even in a program that does not have a QCoreApplication (e.g. klauncher5?).

>> Stefan's trick would allow you to choose your policy from outside Qt 5, using
>> a QSP function such as proposed by Oswald Buddenhagen.  Or you could use
>> a setenv in the "Stefanic" anonymous namespace and a getenv in QSP… ;-)
> 
> Even then, you'd want a fallback choice when no explicit choice is made "from outside Qt 5".

Yes, just whatever was built in to Qt 5, as happened with the graphics-engine choice in Qt 4.

>> Yes, config paths have to be nailed down too.  I have no strong feelings
>> about /etc/xdg or ${prefix}/etc/xdg, except that we might as well keep things
>> in the MacPorts family for now… :-)
> 
> Under MacPorts it'd of course be ${prefix}/etc/xdg .

Agreed.

But you could also use the above approach to "tune" QSP to "linuxy" + MacPorts prefix,
or Fink prefix, or Homebrew prefix or just "policy 1" and no prefix.  That can be coded
at the qstandardpaths.cpp level.  See the QStandardPaths::setTestModeEnabled()
method, for example.  QSP *does* have some data-state after all… :-)

Cheers, Ian W.