[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

Hello René,

On 04/03/2015, at 12:55 AM, René J.V. Bertin wrote:
> 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).

This is nothing to do with KDE 4.

Qt 4 (repeat Qt 4) had an option to choose a graphics system: Qt's raster-graphics, OpenGL
or native.  You could set this option at Qt 4 installation time OR via an environment variable
OR via a QApplication::setGraphicsSystem(QString xxx) call at execution time.

If you chose nothing, the defaults would be native (Qt 4.7, Linux), native (Qt 4.7 and 4.8,
Apple OS X) or raster (Qt4.8 Linux, but not OS X).

> I also don't know what Oswald and Stefan tricks are,

Oswald's suggestion is not a trick, but merely a comment Oswald Buddenhagen made
on your suggested patch at https://bugreports.qt.io/browse/QTBUG-44473.  I hope you saw
his suggestion.  It is analogous to the QApplication::setGraphicsSystem() method referred to
above and to the setTestModeEnabled() method that is already in QSP.  It would be a nice
clean way to set a "Linuxy" mode in QSP on Apple OS X.

I described Stefan's trick to you two days ago.  See [1], [2] and [3], to recapitulate.  It achieves
the goal you stated in your email of 1st March, on this thread, where you said (my emphasis):

> I've started to look at how the ApplicationAttributes (AA_*) feature works. That's just a static
> member value of a private QApplication subclass, which is initialised outside of a function.
------------------------------------------------------------------------------------
> That would only work to define a default at Qt's compile time,
> and not at the client compile time like I am after. 
------------------------------------------------------------------------------------

Stefan Majewski's trick DOES define a default at client compile time.  That is why I told
you about it.  What is more...

          it takes effect BEFORE main() IS CALLED.

It would be ideal for setting anything "Linuxy" that you want.  Not just for QSP, but
also for dealing with the "heuristic" menu mode and other Qt-related problems that
affect KF5 or KDE 4 applications, but may be accepted or unnoticed in other apps.

In KDE Games with Qt 4.7, Stefan's trick was used to ensure that all games used
raster graphics for better performance, without affecting the wider group of ALL
KDE applications.  We want to affect all KF5 or KDE 4 apps, without affecting the
wider group of all Qt5-based apps, so a similar trick could be used.

It worked by using a quirk of C++ known as an "anonymous namespace".  In C++,
the code inside such a namespace can instantiate and execute an "anonymous
global object" automatically and before other code is executed.  In [1] (Review
Board) and in the comments in [2], there is more discussion of how it works.

In KDE Games, Stefan put this code inside the KDE Games library (libkdegames),
which every KDE Game links to.  Thus it could be used without affecting other KDE
or Qt apps.  We could put something like it in kdelibs4 on Apple OS X, where Qt 4.8
defaults to native graphics.  But in June last year I found that it was easier for me to
put a fix in KApplication, to make all KDE 4 GUI apps use raster graphics, with one
exception (kmymoney4).  It fixed a lot of graphics glitches, such as unreadable
buttons (black-on-black) in KDevelop.

In KF5 and Qt5 I have not yet worked out how we could inject an anonymous
namespace whenever a KF5 application or other executable is built, unless we
build a "one-source-file" library which is always linked into a KF5 build on MacPorts,
much as libkdegames5 is linked into every game in KF5.

Maybe you, Marko and Jeremy could work something out.  Your combined knowledge
of CMake, MacPorts and portgroups is far greater than mine.

> but please, I thought we'd agreed that we do not want to rely on environment variables
> in production code.

We did, but that was in regard to using $XDG_DATA_DIRS and $XDG_CONFIG_DIRS
globally within all user-spaces in Apple OS X.  There is no problem with using globals
within one Shell (command-window) for testing and development purposes, or even
prepending an env var setting to a single command-line… :-)

Still less is there a problem with setting (or not setting) an env var via setenv(), within a
program, and then using getenv() to check its existence or value somewhere else.  That
is what I was suggesting...

>> 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").

I agree, naturally, re patching every client executable.  Who wants to do that?

The default can be whatever Qt 5 provides as "standard" on Apple OS X.  You will
only change that to something else (*not* the default) if you run code (or commands)
that make the change.  I am suggesting you look at the "Stefan trick" for that --- as a
small addition to every build of a KF5 (or KDE 4) application or utility on Apple OS X.

> 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.


In closing, I hope you will read carefully what I have said, but I don't care if you disregard
it again.  Maybe you think I am some boring old f--t who can be safely ignored.  If so, it is
your loss.

But please don't go against the Macports, KF5 and Qt5 developers so much.  You
will only make trouble for all of us on KDE-Mac… and we all need to work together
to solve the technical problems our KDE-Mac group faces.

All the best, Ian W.

[1]
https://svn.reviewboard.kde.org/r/6810/
[2] https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/chooserastergraphicssystem.cpp
[3]
https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/diff/CMakeLists.txt?rev=748aa8c8f0e262b1edb7a3166a08528b620bf7bc&rev_to=3c7d109436ab58550a662687c04a42e6e4aec7f0