Correct the comment: say what was measured, not what was assumed

Two claims in the previous comment were wrong.

"Qt implements F10 on Windows but not on X11" was inference I cannot test
here. What is measured is narrower and enough: QMenuBar given Key_F10
directly leaves it unaccepted, and sent to the window the key never reaches
the menu bar at all, because a key press goes to the focused child widget.

"&Édition takes É, which is not on a UK or US keyboard" was wrong outright.
It came from running an uninstalled binary, which cannot find its .qm files
and falls back to the French source strings. With translations loaded the
menus read File, Edit, Project, Display, Settings, Windows, Help, and Alt+E
opens Edit.

The comment now also says plainly that this is convenience rather than
access: Alt tap focuses the bar and Alt with a letter opens a menu, both
verified working, so the menus were already reachable without a mouse. F10
is the key people reach for out of habit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtMZqGEiUMvDBqcFvVG2vb

sources/qetmainwindow.cpp

@@ -264,11 +264,18 @@ void QETMainWindow::checkToolbarsmenu()
 	@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.
+	F10 is what most applications use for this, and QMenuBar does not handle
+	it: given the key directly it leaves it unaccepted, and sent to the window
+	it never reaches the menu bar at all, because a key press goes to the
+	focused child widget. So the press fell through to whichever widget had
+	focus and looked like nothing happening.
+
+	This is convenience, not access. Qt already provides two keyboard routes
+	into the menus and both work: a bare Alt tap focuses the bar, and Alt with
+	a menu's letter opens it. This adds the key people reach for out of habit.
+
+	A shortcut rather than a keyPressEvent() override, for the reason above --
+	the window never sees the key while a child holds focus.
 */
 void QETMainWindow::activateMenuBar() {
 	QMenuBar *bar = menuBar();