-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120403/
-----------------------------------------------------------
(Updated Sept. 30, 2014, 10:42 p.m.)
Review request for KDE Software on Mac OS X, kdelibs and Qt KDE.
Changes
-------
Thomas, it seems you provided the solution:
```C++
#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)) {
continue;
}
checkList.append(mm);
qDebug() << "####" << level << "widget is QMenu" << mm <<
mm->title() << "with parent" << mm->parentWidget();
if (isMenubarMenu(mm)) {
ret = true;
goto done;
}
}
}
}
done:;
level -= 1;
return ret;
}
#endif
```
(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
Description
-------
This is a spin-off of RR https://git.reviewboard.kde.org/r/120355/
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
Diff: https://git.reviewboard.kde.org/r/120403/diff/
Testing
-------
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.
Thanks,
René J.V. Bertin
