[KDE/Mac] KDE-srcbuild, KMyMoney and raster graphics

Ian Wadham iandw.au at gmail.com
Tue Jun 3 10:33:47 UTC 2014


Hi guys,

I now have working a system for building KDE 4.13 from source on
Apple OS X, based on kedsrc-build, and can test it independently
of MacPorts and my previous KDE installations.  It is still in a rather
hackish form, so I need to tidy it up and document it. BTW, some days
Baloo compiles and builds and some days it does not. It is still having
features added, even in KDE 4.13. Either way, a lot of apps still build
and run OK, with or without Baloo.

KMyMoney, as you know, crashes on Apple OS X if raster graphics
is enabled. The problem turned out to be highly intractable.

KMM starts by showing a splash screen, then it creates 11 overlaid
widgets, each of which seems to load data from the user's accounts
file or database, using KIO to retrieve images and data. Then it displays
a tip dialog.

I think it is the busiest startup sequence I have ever seen and KIO floods
the log with messages, probably on multiple threads. So it is very difficult
to see what is going on and where the KDE graphics may be failing. I think
Qt is getting mixed up between when it should be using native graphics
within a native main window and when it should (or should not) be
switching to raster graphics.

I tried to simplify things by disabling the splash screen and the tip
dialog (successfully) and then by disabling most of the 11 overlaid
widgets (unsuccessfully). The latter made KMM crash even when
raster graphics was off.

So what I am now proposing is a scheme for turning on raster graphics
by default, but allowing specific applications, such as KMyMoney, to
call a new static method, KApplication::doNotUseRasterGraphics(),
before creating the KApplication, and so stay with native graphics.

In addition, there is a new environment variable called RasterOff. If
this is defined, applications stay with native graphics. It can be used
for before-and-after testing of apps. For example the following:
    RasterOff=true open /Applications/.../kbounce.app
will start KBounce in slow, black-on-black mode, whereas
    open /Applications/.../kbounce.app
will start KBounce in raster graphics mode at normal speed.

This environment variable could also be used, in an emergency, to
work around a case where a second app is found not to be compatible
with raster graphics. In time, the app could then be patched to use
KApplication::doNotUseRasterGraphics().

Attached is a patch for kdelibs/kdeui/kernel/kapplication.* that
implements all this, and another patch to fix KMyMoney so as
not to use raster graphics.

Please let me know what you think.

All the best, Ian W.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: KDElibsRaster.patch
Type: application/octet-stream
Size: 2618 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140603/e2a6f3bc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KMMRaster.patch
Type: application/octet-stream
Size: 459 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140603/e2a6f3bc/attachment-0001.obj>
-------------- next part --------------





More information about the kde-mac mailing list