Review Request 120403: [OS X] adapting KMenu::addTitle to OS X menubar specifics

René J.V. Bertin rjvbertin at
Tue Sep 30 21:42:29 BST 2014

This is an automatically generated e-mail. To reply, visit:

(Updated Sept. 30, 2014, 10:42 p.m.)

Review request for KDE Software on Mac OS X, kdelibs and Qt KDE.


Thomas, it seems you provided the solution:

#ifdef Q_OS_MAC
static bool isMenubarMenu(QMenu *m)
{   bool ret = false;
        static int level = -1;
    QList<QMenu*> checkList;
    level += 1;
    if (m && m->menuAction()) {
        QAction *mAct = m->menuAction();
        qDebug() << "##" << level << "isMenubarMenu(" << m << m->title() << ") menuAction=" << mAct << mAct->text();
        foreach (QWidget *w, mAct->associatedWidgets()) {
            if (w == m) {
                goto done;
            qDebug() << "###" << level << "associated widget" << w << w->windowTitle() << "parent=" << w->parentWidget();
            if (QMenuBar *mb = qobject_cast<QMenuBar*>(w)) {
                qDebug() << "#### widget is QMenuBar" << mb << mb->windowTitle() << "with parent" << mb->parentWidget();
                ret = true;
                goto done;
            else if (QMenu *mm = qobject_cast<QMenu*>(w)) {
                if (checkList.contains(mm)) {
                qDebug() << "####" << level << "widget is QMenu" << mm << mm->title() << "with parent" << mm->parentWidget();
                if (isMenubarMenu(mm)) {
                    ret = true;
                    goto done;
    level -= 1;
    return ret;

(still with the debugging output of course)

It correctly detects even kdepim's `MessageList::Core::Widget` message list sort order, aggregation and theme menus (sub-sub menus of the View menu). For now I've kept the "normal" title format for menus not attached to a QMenubar at all, we'll see how often that leads to deviant context menus.

Repository: kdelibs


This is a spin-off of RR

As described in that RR, OS X cannot render menu items that were created using `KMenu::addTitle`. Without a Qt patch, that function will even provoke a crash. With a patch, the items are rendered barely legibly once, and then render as empty space in subsequent menu openings.
The main object of that RR is to present and discuss a workaround at the client level, emulating `KMenu::addTitle`. In this RR, I present a draft adaptation of that function itself.

The main goal as I see it is to modify the function just enough so that it changes its behaviour for items that will or can be rendered in the Mac's global menubar, using non-Qt code. Pop-up menus that are not attached to that structure are rendered through Qt and can show all the style formatting they can under Linux as long as it's not tied to X11 directly.
It's probably impossible to cater to all possible use cases, so I'd propose to focus on the situations we can detect from inside `KMenu::addTitle`. That is, *if* we want to ease the client's burden of obtaining a sensible menu item *and* we want to maintain support for the intended/expected style in the menus that can actually support them. (KDevelop's context menu its Project view is a prime example.)
The other goal (secondary for KDE/Mac for the time being) is to come up with a patch proposal for Qt5's `QMenu::addSection`, because its current use of texted separators makes it equivalent to `QMenu::addSeparator` on OS X. (= you get a separator instead of an item showing the title text.)

I have not found a way to detect reliably that a menu is attached to the global menubar. There are functions that are supposed to allow this (KMenu::isTopLevelMenu, QMenu::macMenu) but they don't work as expected. So what I propose here is to emulate the styled menu title when adding to a KMenu that is somehow associated to a KMenu belonging to a KMainWindow that has a menubar. This can probably lead to false hits, and I have already learned that it doesn't catch all the intended cases either (e.g. MessageList->Sorting menu under KMail's View menu is apparently not yet attached when addTitle is called). So I'm following Thomas's suggestion to publish the draft for feedback.

In case anyone wonders about the emulation code (when notMacMenuBar==false): I'm open for suggestions but this is the only approach I've found to create an entry that stands out. It's not impossible to to obtain the font OS X uses for menubar menu items (Lucida Grande 14; requires 2 extra functions), but changing font attributes (bold, underline, overline etc) has no effect. (The bold font version file is available, so it might be possible to get the bold font rendered by specifying it as a full font spec and not as an attribute but I wouldn't know how to achieve this.)

Diffs (updated)

  kdeui/widgets/kmenu.cpp 7dab149 



On OS X 10.6.8 with kdelibs git/kde4.14 . Currently the draft does nothing on other OSes, and the actual "emulation" code (when notMacMenuBar==false) can go conditional if there are no other platforms where a similar approach could be desired.


René J.V. Bertin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list