[KDE/Mac] OS X observations

[Ian Wadham]

Hi René,

On 02/01/2015, at 8:59 AM, René J.V. Bertin wrote:
> I've been giving some renewed love to Calligra (git/master) on OS X, this time working straight towards a MacPorts Portfile.
> Turns out there was no need for many new modifications to make things build, but there are a few issues at runtime:
> 
> - KStandardActions isn't used to create the standard menus. As a result, menu roles aren't set, or rather, they're left to Qt's default setting, which means that without a patch it (Qt) will use text-based guessmatics ("heuristics") to determine which action should go under OS X's Application menu items About and Preferences. Esp. that Preferences menu item is a delicate one, given how many Configure actions there tend to be. I'm adding the required setMenuRole() calls to put the correct Configure action under the Preferences menu item, where this isn't already the case.
> 
> - calligraflow and karbon are somehow exchanged. Flow will start identifying itself as Flow in the menu bar, but before I added the setMenuRole() call (see previous point) there was a Configure Karbon menu; the About will also be for Karbon ... and in order to open vector graphics documents for editing it's calligraflow I have to start. The Karbon application does the opposite. Any idea what might cause this?
> 
> - I don't get a Configure action (nor Preferences menu item) in Flow (i.e. when launching the karbon executable...) is that normal?

Maybe there is some problem in the handling of the *ui.rc files in KXmlGui* classes on OS X… :-(

Or perhaps Calligra loses its way because it is being started by Apple OS X "open" and not via
*.desktop files (which are perhaps more complex than usual in Calligra).  Also, anything that goes
via plugins, KParts or services could be affected by problems in kdeinit4, klauncher and kded4
on Apple OS X.  Do the debug messages in the log output give any clue?  Kdeinit4 and friends
are quite verbose if you turn them on in the KDebugDialog app, as you know… :-)

> - The actual Karbon application (launched through the calligraflow executable) crashes when I close a modified document and discard the changes. The backtrace shows that this is due to nested event handling that is the result of deleting a QObject-derived object inside an event loop that has events queued for it (or deleting it from a thread that didn't create the object). To be exact, the crash occurs in QAction::isEnabled which gets called because of some kind of menubar update event, presumably after the corresponding menu has been deleted.
> Does this ring a bell? The likely fix is to use `foo->deleteLater()` instead of `delete foo` (see the documentation for deleteLater()), but what object(s) would need to be treated that way? Presuming that this is not somehow related to the karbon/flow "masquerading" ...
> 
> - When I let the aforementioned crash be caught by DrKonqi, something is off too. The DrKonqi application that launches appears not to take my settings into account: it opens with default dimensions instead of the last used dimensions, and shows icons in its buttons (which it shouldn't). Worse, I'm running a patched kde-runtime version that lets DrKonqi call lldb ... and this functionality is absent from the DrKonqi that gets called. Does this mean that a local copy of the relevant code is being used?

Maybe Calligra is using its own crash handler, rather than the default handler in the KCrash class.
See http://api.kde.org/4.14-api/kdelibs-apidocs/kdeui/html/namespaceKCrash.html.  Look for stuff
like "setCrashHandler" in Calligra.

> On the positive side, why was calligrasheets excluded from the OS X product set? It builds fine, and at least opens the provided templates without issue.

Great work, René!  I think you have taken on a real challenge with Calligra, but it would be a real
coup to get it going on MacPorts, judging by what I have seen on:
https://www.google.com.au/search?q=calligra+vs+libreoffice&ie=utf-8&oe=utf-8&gws_rd=cr&ei=SkCnVJvfB8TWmAXz64GACg

All the best, Ian W.