Open the menu bar on F10, and add a test that can answer whether it works

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>

sources/qetmainwindow.cpp

@@ -19,6 +19,7 @@
 #include <QWhatsThis>
 #include <QMenu>
 #include <QMenuBar>
+#include <QShortcut>
 #include <QDragEnterEvent>
 #include <QDesktopServices>
 
@@ -41,6 +42,14 @@ QETMainWindow::QETMainWindow(QWidget *widget, Qt::WindowFlags flags) :
 	initCommonMenus();
 
 	setAcceptDrops(true);
+		//A shortcut rather than a key handler: a key press goes to the
+		//focused child widget, so a keyPressEvent() here would never see F10
+		//while the canvas or a panel holds focus.
+	QShortcut *menu_bar_shortcut = new QShortcut(QKeySequence(Qt::Key_F10), this);
+	menu_bar_shortcut -> setContext(Qt::WindowShortcut);
+	connect(menu_bar_shortcut, &QShortcut::activated,
+		this, &QETMainWindow::activateMenuBar);
+
 }
 
 /**
@@ -251,6 +260,28 @@ void QETMainWindow::checkToolbarsmenu()
 /**
 	Handle the \a e event.
 */
+/**
+	@brief QETMainWindow::activateMenuBar
+	Open the first usable menu, as pressing Alt and a menu's letter would.
+
+	Qt implements F10 for this on Windows but not on X11, so on Linux the key
+	did nothing and the press fell through to whichever widget had focus. F10
+	is the usual way to reach the menus without a mouse, and it matters here
+	because one menu cannot be reached by its own letter at all: "&Édition"
+	takes É, which is not on a UK or US keyboard.
+*/
+void QETMainWindow::activateMenuBar() {
+	QMenuBar *bar = menuBar();
+	if (!bar) return;
+
+	for (QAction *action : bar -> actions()) {
+		if (action -> isVisible() && action -> isEnabled() && action -> menu()) {
+			bar -> setActiveAction(action);
+			return;
+		}
+	}
+}
+
 bool QETMainWindow::event(QEvent *e) {
 	if (e -> type() == QEvent::WindowStateChange) {
 		updateFullScreenAction();