https://bugs.kde.org/show_bug.cgi?id=369276
Bug ID: 369276
Summary: KActionCollection, menu/action reuse and the native
Mac menubar
Product: frameworks-kxmlgui
Version: unspecified
Platform: Other
OS: OS X
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: rjvber...@gmail.com
I'm making another attempt at raising awareness about a Qt platform limitation
on Mac that has potentially severe implications for reuse of QMenus, QActions
and QActionWidgets in multiple menus if one of those is attached to a native
QMenuBar.
In short, this is not possible (because items attached to the native menubar
are reparented away from their original parent), and according to the
documentation it can lead to the menu items (be they actions or submenus) not
appearing or remaining disabled. The documentation isn't explicit which
instances might not appear or remain disabled; practical experience suggests
this only occurs in menus under the toplevel menubar.
Qt versions before 5.3 were not affected to the best of my knowledge; 5.4 and
5.5 would print error messages each time the software added an item to or
removed it from an additional menu.
In other words, the KActionCollection class is compromised on OS X, and that's
not exactly a class that sees only limited use.
The big problem here is that it is near impossible to predict which instances
will be affected. With earlier KTextEditor and Qt versions, for instance, I had
to disable the paste history and bookmarks menus to stop the error messages.
With Qt 5.6.1 and KTextEditor 5.24.0 it is the Mode and Highlighting menus that
are populated almost exclusively with disabled submenus.
The fact that items are reparented suggests that reusing them may also lead to
memory leak, accessing stale objects or double freeing (and indeed I have seen
some crashes that appeared related to menu item reuse).
The most effective solution I've found until now is to disable the native
menubar. Evidently this isn't ideal if the goal is to make KDE applications
look and behave as natively as possible. Also, just setting the
Qt::AA_DontUseNativeMenuBar attribute before any menus are created isn't enough
for all applications. Some may (like KHelpCenter) never show the menubar, some
(those that do not offer a hide/show menu feature like KDevelop) may start
unpredictably with the menubar in hidden state, or hide it at runtime in
reaction to some event.
The alternative solution is to avoid reuse on OS X, either in the source code
or in the ui.rc definition files but it is my experience that it isn't always
trivial to figure out what to disable where.
I've tried to get some answers about the underlying limitation from the Qt team
on one of their mailing lists, but it is probably worthwhile to start thinking
of workarounds independently. After all the official Qt stance may be "software
just shouldn't do this", like with QMenu::addSection() (which doesn't add a
named section on all platforms).
Reproducible: Sometimes
Steps to Reproduce:
1. Create QMenu, QAction and/or QActionWidget instances
2. Add them to a QMenuBar that corresponds to the Mac native, toplevel menubar
in addition to one or more other menu(bar)s
Actual Results:
the instances (or items therein) may not appear or remain disabled, a priori
only in the toplevel menubar (but that may depend on the order of attribution).
Expected Results:
All instances in all menu(bar)s appear and are enabled as expected
I'm hesitating between calling this a wishlist ticket and something stronger.
KActionCollection sees considerably widespread use, so I'm going to settle with
"Major".
--
You are receiving this mail because:
You are watching all bug changes.
