[KDE/Mac] KMyMoney, KCrash and more on KF5

[Ian Wadham]

Hi Marko,

Long time no see.  I have been "resting" for a few weeks (that's what actors
say when they are out of work).  Truth is I am stuck on a batch of problems
which prevent Dr Konqi, kdeinit4, etc. from working on OS X and am not
going to beat my head against them any more until I get some help from a
KDE core developer.

That help has been promised and I have sent off a whole lot of background
info and detailed questions, but so far no reply.

The science course I give for lay persons resumes in a few days, so I have
been busy preparing notes and slides...

On 23/08/2014, at 7:09 PM, Marko Käning wrote:
> as you noticed on macports-devel I am eventually able to run qt5 apps which need a session dbus!
> \o/
> 
> Well, thanks to Cristian, one of these apps is the frameworks branch version of KMyMoney!
> :-)

Excellent.

> Actually, it is not very surprising that this application still aborts at some stage: That is simply
> due to the fact that my definitions of standard locations for configuration and data files aren’t
> yet fully correct on the OSX/CI system. But I am confident to get there. :)

Looking at the log, I don't think it gets that far.  I think all those "QPainter::begin: Paint device
returned engine == 0, type: 2" messages mean that it cannot find a paint engine (0) and that
it is looking for an engine of type 2 (Mac OS X's QuickDraw, whatever that is).  The messages
might be a red herring though.  I'd expect Qt 5 to be looking for type 10 by default (i.e. Raster)
or possibly type 3 (Mac OS X's Quartz2D (CoreGraphics)), as Qt-Mac 4 does.  See enum
QPaintEngine::Type.

Try command "QT_GRAPHICSSYSTEM=raster qt5/extragear/office/kmymoney… etc." or
"QT_GRAPHICSSYSTEM=native qt5/extragear/office/kmymoney… etc.".  Or maybe you have
that patch in KMyMoney that negates Raster graphics.  You should not.  That patch is in
KApplication and apps should be using QApplication in KF 5.

If you still have KApplication AND the patch, "RasterOff=true qt5/extragear/office/kmymoney… etc."
might get you off the ground, but don't expect to fly very far… :-)

> —
> Anyway, I thought, I share the crashlog and the console output with you guys, as there is also the
> expected inability to start DrKonqi on OSX:
> ---
> Could not find drkonqi at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kcrash/inst/lib/libexec/drkonqi
> ---
> which must fail, since its executable is located in the plasma-workspace framework according to
> David [1]. Up to now I haven’t tried to build that framework, because I thought that it won’t
> build on OSX anyway...
> 
> Since the discussion about placement of DrKonqi [2] lead to the decision to put it into
> plasma-workspace we now DO HAVE A PROBLEM for KF5 on OSX, as we won’t ever build plasma-workspace!
> 
> Any ideas how to tackle this? Looks like we need a light-weight version of plasma-workspace
> which doesn’t require X11 but including DrKonqi, or suggest to move DrKonqi someplace else??

What a shemozzle!!!  And I am surprised at David saying "In any case, this isn't related to OSX."
I suppose he means that you can carry on without building it, but of course you cannot diagnose
any crashes relating to KF 5 or OS X porting errors in the apps you are building and running.

> [1] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018142.html
> [2] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-April/014384.html

IMHO the reasoning in [2] is very much centred on Linux/KDE/Frameworks.  They decided to get
rid of kde-runtime, but where to put Dr K?  So they bundled it into plasma-workspace.  We might
find some other items that are needed by all KDE apps on all platforms.  KHelpCenter?  KGlobalAccel?

Surely this problem applies not only to OS X, but also to Windows and other Linux desktops, such as
Gnome (and a few others).  The KDE core developers really should think again about these cross-platform
runtime things and put them in some more logical place.

For now, you might be able to build Dr K as a standalone app, but it would have to be ported to Frameworks
and I don't suppose any of the core developers is doing that… :-(

All the best, Ian W.