QEvent - detecting number key press

[mabeghin]

I'd like my app to change tab with Ctrl+1, Ctrl+2.. (or Cmd+1 on macOS) like web browsers.
The key with number 1 on a french keyboard has code "&", and might have other QEvent::key value on other keyboard. What is the correct way to know if user pressed the key with the number 1 on it ?

[Axel Spoerl]

If you can live with ALT instead of CTRL, you cut just use shortcuts, as described here.

Otherwise you have to filter key events and check for the CTRL modifier, more or less like this

bool eventFilter(QObject *obj, QEvent *event) override
{
    Q_UNUSED(obj); // argument not needed if only the tab view is handled
    if (event->type() != QEvent::KeyPress)
        return false;

    QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event);
    if (!keyEvent->modifiers().testFlag(Qt::ControlModifier))
        return false;

    switch (keyEvent->key()) {
         case Qt::Key_1:
             // change tab
             return true;
        // ... //
        case Qt::Key_2:
             // change tab
             return true;
        default:
        return false;
    }
 }

[mabeghin]

@Axel-Spoerl Thanks for the reply. This is ok with a qwerty keyboard but on a French keyboard, the key with the 1, without shift pressed, does "&". But in browsers and even Qt Creator Ctrl+& works as Cmd+1 on a Qwerty keyboard. So I suppose there's a trick to get it working on any keyboard...

[Axel Spoerl]

Qt gets it’s key events from the window management system. I have a French keyboard here and it works for me. Maybe the keyboard settings on OS level are wrong. I am using Linux /X11

[Pascal V.]

Hi, i would like to second the behavior found here.

I am trying to migrate from Qt5.3.1 to Qt5.15.2.
I am working on windows 10 with french keyboard

After migration, i can't trigger QAction affected with a shortcut "Ctrl+1" anymore using keys above alphabetic keyboard.
It is still triggered when pressing "Ctrl+1" using numpad.
In Qt5.15.2, if i modify QAction::setShortcut parameter to "Ctrl+&" the shortcut is handled and triggers the QAction

I produced a small code to log keys and handle QAction triggering
Here is the code that logs keys

bool TestListsMainWindow::eventFilter(QObject *obj, QEvent *event)
{
	if (event->type() != QEvent::KeyPress)
		return false;

	QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event);
	qDebug() <<keyEvent->text();
	return false;
}

Here is the slot that handle trigger signal

void TestListsMainWindow::switchBool()
{
	m_bOne = !m_bOne;
	qDebug() << "Switching";
}

And here is the signal connection

	QAction* l_action = new QAction(this);
	addAction(l_action);
	l_action->setShortcut(QKeySequence("Ctrl+1"));
	connect(l_action, &QAction::triggered, this, &TestListsMainWindow::switchBool);

	installEventFilter(this);

Qt5.3.1 result striking 5 first keys from 1 to 5, then doing it while holding Ctrl :

"&"
"é"
"""
"'"
"("
""
Switching
"é"
"""
"'"
"("

Qt5.15.2 result striking 5 first keys from 1 to 5, then doing it while holding Ctrl:

"&"
"é"
"\""
"'"
"("
""
"&"
"é"
"\""
"'"
"("

From what i can see, trying multiple combinaisons of Ctrl + 1, (using Shift, or Capslock feature), the behavior is more consistent in Qt5.15.2, but it is different from Qt5.3.1.
In Qt5.3.1 pressing '&' never displays '1' with QKeyEvent::text(), discarding state of caplock. And the shortcut is always triggered.
In Qt5.15.2 when capslock is On, '&' is displayed as/changed to '1' with QKeyEvent::text(), thus correctly handled by the shortcut only when '1' is displayed.

Unfortunatly as stated by mabeghin, it seems different from the one found in web-browsers and QtCtreator.

Is it a correction ?
And is the correction a good thing compared to previous Qt version and existing behaviors in others applications?

[Axel Spoerl]

There is a similar issue on Linux/XCB. I am fairly (albeit not entirely) sure, that the underlying principle is the same. Qt used to read keyboard input at OS level, where the window manager should be the only consumer. This is to ensure that the window manager is seeing all its shortcuts like ctrl+alt+del. Back in the days, a Qt application could theoretically intercept such a shortcut and handle it without the window manager knowing. The current logic is different from that: The window manager will see and consume all its shortcuts. Could it be, that ctrl+1 is a WM shortcut on French systems?