[KDE/Mac] Fixing graphics problems in KDE/Qt on Apple OS X
iandw.au at gmail.com
Sun Apr 27 03:34:31 UTC 2014
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 :
>> 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.
>> 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
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
as described in two CMake manual sections at
> 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:
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.
I'd like to have a closer look at option 3 [make sure the code does
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 . 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.
This code relies on some less well-known features of C++.
The comments explain what is going on.
More information about the kde-mac