[KDE/Mac] Shadow-rendering glitch in 4.14.1-Parley due to software rendering mode on MacPorts' KDE 4.13.3?

[Ian Wadham]

Hi Marko,

Sorry for the earlier noise-message.  I hit the wrong button.

On 21/11/2014, at 8:48 AM, Marko Käning wrote:
> I just happened to have a closer look at parley [1] on OSX/MacPorts. :)
> 
> Inge as parley’s developer asked me to install its latest version, which is why
> I created a new branch in our MacPorts/KDE git repo called ‘KDE4.14’, which
> contains also parley and the needed libkdeedu [2]. All the other stuff can be
> used from current KDE 4.13.3 installed via MacPorts.
> 
> First thing I noticed is, that there seems to be some rendering glitch which I
> filed a bug report for in [3].
> 
>    Since you, Ian, had spotted stuff like that for various applications,
>    I thought you might have an idea what this could actually be. Obviously
>    some transparency and shadow is involved here… Check out the screenshots
>    for OSX and Linux in [3]!
> 
> If the raster graphics system would be responsible for this, I should be able
> to switch the application to native or opengl mode like this, right?
> 
>  $ open /Applications/MacPorts/KDE4/parley.app --args -graphicssystem native
>  $ open /Applications/MacPorts/KDE4/parley.app --args -graphicssystem opengl

What you need, to suppress the raster graphics patch in KApplication for OS X, is:
$ RasterOff=true open /Applications/MacPorts/KDE4/parley.app --args -graphicssystem native
$ RasterOff=true open /Applications/MacPorts/KDE4/parley.app --args -graphicssystem opengl

Without the "RasterOff=true" environment-variable, the patch overrides anything
that may have been set previously by parameters, environment variables, etc.

The patch had to be done that way because there is no standard way, across various
versions of OS X, to introduce an environment variable or parameter (e.g. --args
-graphicssystem raster), whenever we run a KDE app in OS X.

> But these didn’t change anything regarding the frame for me… :( OpenGL didn’t
> render the progress bars’ round edges as nicely as raster and native did.

If it turns out that Parley works better without raster graphics, you can patch Parley
as was done for KMyMoney4, i.e. following what the raster graphics patch says here:
    +  /**
    +   * Use before creating KApplication in an app which fails with raster
    +   * graphics, such as KMyMoney. Most KDE apps on OS X run better with raster.
    +   */
    +  static void doNotUseRaster();

insert "KApplication::doNotUseRaster();" (e.g. in main.cpp), somewhere before
Parley creates the KApplication object.

> Anyways, I hope that you, Ian, will have a clue what’s going on here.

Not really.  Could be a layout-handling problem (manner of use of QLayout in Parley
or the implementation of QLayout in OS X). The white rectangle seems to have come
out too large in the OS X implementation of Parley.

Cheers, Ian W.

> Inge and I somehow remember some issues with OSX, shadows and transparency…
> So, perhaps one would have to work around this on OSX for the time being?!
> 
> ---
> 
> Apart from this Parley appears to be a very nice learning tool!!! :-) 
> 
> 	Congratulations, Inge!!!!!
> 
> 	AND: Nice to have this running on OSX via MacPorts!
> 
> 	I was able to download collections via the integrated hotnewstuff
> 	functionality!     :-D     Absolutely COOL!!!! 
> 
> Greets,
> Marko
> 
> [1] https://projects.kde.org/projects/kde/kdeedu/parley
> [2] http://commits.kde.org/macports-kde/0744e4e4934ca77c7274b45be1298e9884b0316d
> [3] https://bugs.kde.org/show_bug.cgi?id=341138