Having the generic qt_itemFired: as action would result in the whole submenu tree closing if an item with a sub-menu was clicked on. This is not how native applications behave. They respond by immediately opening the submenu, or do nothing if the menu is already open. By using submenuAction: as the selector we achieve the same behavior. A complication here is that for some reason we defer associating the submenu NSMenu to an NSMenuItem until QCocoaMenu::setAttachedItem(), instead of doing it in QCocoaMenuItem::setMenu(), or even as part of QCocoaMenuItem::sync(). As a result, AppKit's NSMenuValidation logic will conclude that the item does neither have a submenu, nor a valid target/selector combo to be validated, and will explicitly disable the item. This can be debugged by passing -NSTrackMenuValidation YES to the application. To work around this we explicitly enable the item once we have set a valid submenu for the item. Fixes: QTBUG-114199 Change-Id: I7178e7687066b3fe082454c512ec9c7eab3bded4 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit c8473c090367496885410ce70c0305b6d2b56ce7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
…
…
Description
Languages
C++
84.3%
HTML
4.9%
C
3.9%
CMake
3.6%
Objective-C++
2%
Other
0.8%