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.