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

List:       kde-mac
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-03-03 13:55:43
Message-ID: 3836884.eBJRXDPMiB () patux
[Download RAW message or body]

On Tuesday March 03 2015 23:45:11 Ian Wadham wrote:

> 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

I don't know exactly how KDE4 enforces raster mode (I thought it was a patch in one \
of KDE's overloaded classes). I also don't know what Oswald and Stefan tricks are, \
but please, I thought we'd agreed that we do not want to rely on environment \
variables in production code.


> 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… :-)

I've considered introducing a new QSP state variable (static member). That'd be safer \
from an ABI compatibility point of view, but I don't see how you can control the \
default/fallback policy after building Qt. And I continue to think that that's what \
we need.

We want (and probably need) a way to control the default policy without having to \
patch client code. Not because that's hard to do, but because there's so much of it, \
and if KDE4 is any indication, not always with a clear entry point ("main"). Not only \
would there be a huge quantity of patches to make, we'd also have to maintain those \
changes. Somehow I don't think there will be a lot of enthusiasm to incorporate such \
patches upstream, and even if they do get incorporated, chances are things will \
continue to break (like the "OS X is Unix but doesn't use X11" patches I've had to \
reapply so often) because the majority of developers simply don't think about Mac \
specific little things.

The alternative would be to shift this QSP thing to Qt's platform plugin. But then \
what ... we'd still need a mechanism by which applications can indicate which plugin \
they prefer so that Qt can load the appropriate one without having to specify it \
manually each time the app is launched.

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]