[KDE/Mac] Fixing graphics problems in KDE/Qt on Apple OS X

[Ian Wadham]

Hi Nicolas,

On 26/04/2014, at 9:57 PM, Nicolas Pavillon wrote:
> Thanks for the impressively detailed discussion. I do not intend to discuss the details of the 
> graphical approaches as I am essentially ignorant about them, but more on the way of introducing
> this change in practice. 
> 
>> I found I could force it to switch in one of three ways [2]:
>> 
>> 1. Put --args -graphicssystem raster on the "open" command-line.
>> 2. Define environment variable QT_GRAPHICSSYSTEM=raster,
>>     either by exporting it or by prepending it to the command line.
>> 3. Execute QApplication::setGraphicsSystem("raster") in the app's
>>     code before the QApplication object is constructed.
> [snip]
> 
>> I think either of 1 or 2 could be made part of MacPorts installations of
>> all KDE apps and maybe also Qt apps.
>> 
>> So can we proceed with method 1 or 2 in MacPorts as soon as possible?

I take it that you agree in principle, but I see there are some practical
difficulties … ;-(

> Indeed method 3 seems overkill, as patching is usually not the preferred option. 
> However, I see some possible complications with approaches 1 and 2. To my 
> understanding, they both imply launching applications from the command line, which
> is not the usual way on Mac, with most KDE applications being shipped as Mac application
> bundles. 

I had in mind that we could use a modified plist file, adding something like
ProgramArguments in  file /System/Library/LaunchDaemons/com.apple.taskgated.plist,
but it seems to be not that easy.

I have done some further digging.  From what I can tell, KDE relies on CMake to
generate its plist files from the template file
/opt/local/share/cmake-2.8/Modules/MacOSXBundleInfo.plist.in,
as described in two CMake manual sections at
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:MACOSX_BUNDLE

> So, method 1 would not work, unless the whole process of application bundle generation
> is modified, which seems rather drastic. It would require to create wrapper bundles in which 
> a specific bash command is prepared to launch the application with the desired arguments.

The relevant KDE build code is at 'macro (KDE4_ADD_EXECUTABLE _target_NAME)'
in source file kdelibs/cmake/modules/KDE4Macros.cmake.  It would have to find a
unique custom Info.plist template from some unique location.  That template would be
just like the CMake template, but adding the lines:

        <key>ProgramArguments</key>
        <array>
                <string>${MACOSX_BUNDLE_EXECUTABLE_PATH}</string>
                <string>-graphicssystem</string>
                <string>raster</string>
        </array>

and then supplying a full executable path as the parameter value.

This is tricky, but I am willing to have a go at it if you are interested and the KDE build
guys have no objection to modifying KDE4Macros.cmake some more for Mac OS X.

> Similarly method 2 would be in the same situation, as application bundles blatantly ignore 
> all environment variables set the “normal” way through a .bash_profile, for example. And 
> while Macports can create its own build environment, it does not set anything at runtime 
> (I imagine Homebrew is the same, even though I don’t really know).
> 
> Method 2 could eventually be automated by setting an environment variable for bundle 
> applications, but this approach has been pretty unreliable to my experience. 
> One way is to globally set variables in the file ~/.MacOSX/environment.plist, but this 
> global approach would be up to the user, and is not supported from 10.7. 

I tried the ~/.MacOSX/environment.plist approach and it worked (I am on Lion, 10.7.5),
except that QT_GRAPHICSSYSTEM was then defined for *every* environment (e.g.
Terminal).  Not too bad, I suppose.  It is unlikely there are any synonyms for that symbol
in non-Qt apps.

> There is also the possibility of assigning application-specific variables in the Info.plist
> file of bundles, through the LSEnvironment key. This approach could be used by automatically
> patching the Info.plist of KDE applications, but I don’t know how well it is supported (I remember
> cases with previous OSs where it did not seem to work for me). I made a dummy Cocoa 
> application on 10.9, where it seems to work, but I don’t know if it is also a valid approach for 
> KDE applications.

I tried this, but it does not work for me.  According to StackOverflow it is new in Mountain Lion.
http://stackoverflow.com/questions/12165385/how-to-set-environment-variables-to-an-application-on-osx-mountain-lion
http://stackoverflow.com/questions/7501678/set-environment-variables-on-mac-os-x-lion

I'd like to have a closer look at option 3 [make sure the code does
        QApplication::setGraphicsSystem("raster");
before the QApplication object  is created].  This is a one-line change in libkdegames.
The code to do it is already there.  It just needs to be enabled for Q_OS_MAC [1].  That
would be better than nothing.  At least it would cure the problems in KDE Games,
including KBounce and Palapeli.  I have the access required to make that change.

But similar bugs might surface in other KDE apps, so I'll have a look and see if
there is somewhere in kdelibs to slot it in.  If there is, I could go on bended knee
to the powers-that-be of KDE, OR we could add it as a downstream patch for
KDE 4.13 and 4.14, to cover us for a year or two until KF 5 apps become common.

Cheers, Ian W.

[1] https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/CMakeLists.txt#L105
     https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/chooserastergraphicssystem.cpp
     This code relies on some less well-known features of C++.
     The comments explain what is going on.