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

[Ian Wadham]

Hello Nicolas,

On 28/04/2014, at 1:49 AM, Nicolas Pavillon wrote:
> Considering the different points brought about that, it seems that several options are not really viable. 
> 
> The /.MacOSX/environment.plist approach is not really acceptable as it sets something globally. Furthermore, it is supposedly not
> supported on later platforms, and would require to install files outside of Macports directories, which is to be avoided.

In principle this is wrong and, in my experience, things like that eventually
get up and bite you in the rear end. In practice, it may be a quick-and-dirty
way, if all else fails, for KDE apps on Mac OS X to last out the time until the
coming Qt 5 and KF 5 revolution is over and peace is restored.

The implementations I proposed for the other two options each involve adding
a new file to the KDE build and a patch to a CMakeLists.txt file or a CMake macro.
In one case it would affect the library for all KDE GUI apps, in the other case
the build macros they all use.

> The settings through the application plist file seemed elegant to me, but it seems not reliable depending on platforms, and would 
> probably become a hassle in its implementation, where plist files would have to be changed, possibly up to the cmake port.

No.  CMake allows you to supply your own template for the Info.plist file and
already supports that.  No changes to CMake required.  Two KDE daemons
(background processes), kdeinit and kded, already use that feature, to supply
plist parameters that gain a licence to execute within the Mac OS X environment.

My approach, for all KDE GUI apps, would be to add just one template file to
the KDE macros and patch the macro all GUI apps use for building
(KDE4_ADD_EXECUTABLE), so that it fills in the new template and generates
an Info.plist file for each app that will start the app off with Raster already set
from the command-line.

> In light of this, Ian, if you find a place where it would be possible to patch kdelibs4 to get it done, it would be probably far simpler.
> And even if it is not possible to push it upstream, we could keep the patch downstream for Mac-specific applications. Kdelibs4 is
> already patched at several places already. Not the best solution in principle, but apparently the simplest in practice. 

I will start looking for the place.  At the least, I can fix all KDE Games that way
and they are the most sensitive to Qt's native graphics implementation for Mac.

And I will continue to investigate both implementation possibilities.

It will be nice to fix all KDE apps, just in case there is some Raster-dependent
graphics code lurking in the Plasma and QML libraries, which more and more
KDE apps have been using lately.  We have already seen black-on-black in
KDevelop, which was easily prevented.  Prevention is better than cure.

>> Note: if we can go with one of my three options, it is not necessary to install
>> with +raster.  They all override the installation option.  
> 
> This is a very good point. It would make things really easier, as it is not possible to require specific variants in Macports. 

Yes, you might even be able to drop the +raster variant.  Maybe +docs also
if we can get meinproc4 to behave itself … :-)

Cheers, Ian W.