[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-28 0:15:01
Message-ID: 76BABE4F-ACBF-441C-A93D-7282BC18456D () gmail ! com
[Download RAW message or body]

Hello Nicolas,

On 28/04/2014, at 1:49 AM, Nicolas Pavillon wrote:
> Considering the different points brought about that, it seems that severa=
l options are not really viable. =

> =

> The /.MacOSX/environment.plist approach is not really acceptable as it se=
ts 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 eventual=
ly
get up and bite you in the rear end. In practice, it may be a quick-and-dir=
ty
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 h=
ave to be changed, possibly up to the cmake port.

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

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 alr=
eady 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 pat=
ch downstream for Mac-specific applications. Kdelibs4 is
> already patched at several places already. Not the best solution in princ=
iple, 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-depe=
ndent
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 n=
ot 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 =85 :-)

Cheers, Ian W.


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