OS X observations
Jaroslaw Staniek
staniek at kde.org
Fri Jan 2 23:14:15 GMT 2015
Big thanks for the update, René!
On 1 January 2015 at 22:59, René J.V. <rjvbertin at gmail.com> wrote:
> Hi,
>
> 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?
>
> - 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?
>
> 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.
>
> Cheers,
> René
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
More information about the calligra-devel
mailing list