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

List:       kde-mac
Subject:    Re: [KDE/Mac] Fixing graphics problems in KDE/Qt on Apple OS X
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-04-27 3:34:31
Message-ID: 6DCD8059-33E3-4CB7-B67F-B59F4B032117 () gmail ! com
[Download RAW message or body]

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