mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-25 19:34:13 +02:00
ispyisail
bd6bed8d61
F10 opens the menu bar in most applications and is the usual way to reach the menus without a mouse. Qt provides this on Windows but not on X11, so on Linux the key did nothing and the press fell through to whichever widget had focus. It matters more here than it might elsewhere: "&Édition" takes É for its own letter, which is not on a UK or US keyboard, so that menu has no direct Alt route at all. A window-context QShortcut rather than a key handler -- key presses go to the focused child widget, so a keyPressEvent() on the window would never see F10 while the canvas or a panel has focus. tests/qttest/tst_menubarkeyboard.cpp covers three things: that Alt and a letter opens a menu (the control), that plain F10 does nothing in Qt itself (which is why the shortcut exists, and which will fail loudly if a future Qt starts handling it), and that the shortcut mechanism opens the bar. It uses QTest instead of driving a real X server for a specific reason. xdotool on Xvfb delivers every function key with Alt held: a Qt key logger shows Key_F10 arriving with modifiers == Qt::AltModifier. --clearmodifiers, keydown/keyup pairs, --window targeting and flattening the keycode with xmodmap all made no difference. Two rounds of GUI automation therefore gave confident, wrong answers about F10 -- first that it was broken, then that this very fix did not work. QTest posts the event straight to the widget, so the key arrives as written. What the test does not cover, since initCommonActions() calls QETApp::instance() and constructing that pulls in the whole application: it repeats the wiring rather than driving QETMainWindow. Confirming the real window responds still needs someone to press F10 in a running QElectroTech. Verified by breaking it: bound to F11 instead, the test fails. Qt 5 and Qt 6 both build clean, 6/6 tests on each. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>