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

List:       kde-mac
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2015-03-03 12:45:11
Message-ID: 6A2218FD-43D6-4877-B9B3-9E675644938F () gmail ! com
[Download RAW message or body]

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.

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

Configure | About | News | Add a list | Sponsored by KoreLogic