Problem
The automation bridge can drive button drop-down menus (showMenu → QToolButton::menu() / QPushButton::menu()), but it has no way to trigger or inspect a widget's custom right-click context menu (Qt::CustomContextMenu / customContextMenuRequested, or an overridden contextMenuEvent).
This surfaced while verifying the S-meter config relocation (#TODO link the PR), which moves TX/RX-meter select, peak-hold, decay-speed, and reset into a right-click context menu on the gauge. The bridge could confirm the inline controls were removed (dumpTree) but could not open or read the new context menu — showMenu returns "has no drop-down menu (expected a QToolButton/QPushButton with menu())" because the menu is built on demand in a customContextMenuRequested handler, not attached to a button. So that whole class of UI is currently invisible/undriveable from the bridge.
Proposed enhancement
Add a verb (e.g. contextMenu <target>) that:
- Triggers the target widget's context menu — synthesize a
QContextMenuEvent at the widget (or its center), which fires both customContextMenuRequested (CustomContextMenu policy) and an overridden contextMenuEvent. This must run deferred / on the GUI loop and be re-entrancy-safe like the existing showMenu/openMenu path (the popup runs its own event loop).
- Exposes the resulting
QMenu for inspection + invocation, reusing the existing menu-walk/serialisation already used by showMenu (items, enabled/checked state, separators, section/header rows, submenus) so a driver can read the structure and invoke an item by text/path.
Nice-to-haves
- Handle
QWidgetAction header rows gracefully in the menu serialisation (the S-meter menu uses disabled QWidgetAction + QLabel for section titles, since QMenu::addSection() text doesn't render under the app's menu styling — so a generic header type in the dump would help).
- Allow targeting by the same
resolveWidget rules as invoke/showMenu (objectName, class, accessibleName, scope).
Why
Context-menu-driven config is a growing pattern in the UI (S-meter now; likely more as we de-clutter applets). Without this verb, those surfaces can't be regression-tested or automated through the bridge, which undercuts the bridge's value as a UI test harness.
Related: #3813 (other bridge driving gaps).
🤖 Generated with Claude Code
Problem
The automation bridge can drive button drop-down menus (
showMenu→QToolButton::menu()/QPushButton::menu()), but it has no way to trigger or inspect a widget's custom right-click context menu (Qt::CustomContextMenu/customContextMenuRequested, or an overriddencontextMenuEvent).This surfaced while verifying the S-meter config relocation (#TODO link the PR), which moves TX/RX-meter select, peak-hold, decay-speed, and reset into a right-click context menu on the gauge. The bridge could confirm the inline controls were removed (dumpTree) but could not open or read the new context menu —
showMenureturns "has no drop-down menu (expected a QToolButton/QPushButton with menu())" because the menu is built on demand in acustomContextMenuRequestedhandler, not attached to a button. So that whole class of UI is currently invisible/undriveable from the bridge.Proposed enhancement
Add a verb (e.g.
contextMenu <target>) that:QContextMenuEventat the widget (or its center), which fires bothcustomContextMenuRequested(CustomContextMenu policy) and an overriddencontextMenuEvent. This must run deferred / on the GUI loop and be re-entrancy-safe like the existingshowMenu/openMenupath (the popup runs its own event loop).QMenufor inspection + invocation, reusing the existing menu-walk/serialisation already used byshowMenu(items, enabled/checked state, separators, section/header rows, submenus) so a driver can read the structure andinvokean item by text/path.Nice-to-haves
QWidgetActionheader rows gracefully in the menu serialisation (the S-meter menu uses disabledQWidgetAction+QLabelfor section titles, sinceQMenu::addSection()text doesn't render under the app's menu styling — so a generic header type in the dump would help).resolveWidgetrules asinvoke/showMenu(objectName, class, accessibleName, scope).Why
Context-menu-driven config is a growing pattern in the UI (S-meter now; likely more as we de-clutter applets). Without this verb, those surfaces can't be regression-tested or automated through the bridge, which undercuts the bridge's value as a UI test harness.
Related: #3813 (other bridge driving gaps).
🤖 Generated with Claude Code