I noticed that the Tools/Mode and Tools/Highlighting menus remain empty, except for the *disabled* submenus for the various known categories and the items: "Normal" & "New Filetype" in Tools/Mode and "None" in Tools/Highlighting Both Kate5 and KDevelop5 are affected. Curiously this happens only when I use Qt's normal/default Cocoa QPA; when I start the applications in X11 mode (`-platform xcb`) the menus behave normally. See the screenshots I'll be attaching. I'm currently using Kate 16.08.0 and KTextEditor 5.24.0 Reproducible: Always Steps to Reproduce: 1. Start Kate5 or KDevelop5 2. Open a document of a supported type for which highlighting definitions exist 3. Check the Tools/Mode and Tools/Highlighting menus Actual Results: See the Cocoa screenshot and notice how the submenus are present but disabled. The New Filetype menu item has no effect. Expected Results: See the XCB screenshot: populated submenus The highlighting mode can be selected normally via the status bar widget, so the issue cannot be explained by missing highlighting definitions. The same software versions do NOT have the "New Filetype" Tools/Mode menu item on Linux.
Created attachment 101235 [details] screenshot of KDevelop running in native mode on OS X, showing the crippled Tools/Mode menu
Created attachment 101236 [details] screenshot of KDevelop running in X11 mode on OS X, showing a normal Tools/Mode menu (with an additional item)
So this appears to be related to using the Mac toplevel menubar: adding QCoreApplication::setAttribute(Qt::AA_DontUseNativeMenuBar); to main() gives functional and populated Mode an Highlighting menus too.
According to QMenu::isEnabled() and QAction::isEnabled(), the submenus and their actions are all enabled. However, according to the QMenu documentation: QMenu on OS X with Qt Build Against Cocoa QMenu can be inserted only once in a menu/menubar. Subsequent insertions will have no effect or will result in a disabled menu item. See the Menus example for an example of how to use QMenuBar and QMenu in your application. and according to the QWidgetAction docs: OS X: If you add a widget to a menu in the application's menu bar on OS X, the widget will be added and it will function but with some limitations: 1. The widget is reparented away from the QMenu to the native menu view. If you show the menu in some other place (e.g. as a popup menu), the widget will not be there. So it seems we're looking at a similar error/limitation as the one that previously led to error messages about menu items being added to or removed from more than 1 menu. Those messages no longer appear in Qt 5.6, but clearly the underlying reason is still there.
Created attachment 101240 [details] Patch to work around the issue on OS X Moving the Mode and Highlighting menus into the popup/context menu makes them behave as expected. It seems at least the Mode menu becomes better behaved when a copy is preserved in the toplevel menubar, but there's little point in keeping potentially broken copies around. The patch also provides a number of more Mac-like shortcuts for typical menu actions.
(In reply to RJVB from comment #5) > Created attachment 101240 [details] > Patch to work around the issue on OS X > > Moving the Mode and Highlighting menus into the popup/context menu makes > them behave as expected. It seems at least the Mode menu becomes better > behaved when a copy is preserved in the toplevel menubar, but there's little > point in keeping potentially broken copies around. > > The patch also provides a number of more Mac-like shortcuts for typical menu > actions. If this is still an issue are you able to please submit your patch to https://invent.kde.org/websites/kate-editor-org/-/merge_requests Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.