Fwd: Qt 5.7+ and Command+Shift shortcuts on Mac

[René J.V. Bertin]

On Friday January 06 2017 18:33:01 David Faure wrote:

> Well, you didn't say either way, so I tried to guess from your description, 
> and guessed wrong.

No problem, can't be right all the time (and it's Friday night at that) ;)

> > the shortcut shows up correctly (Command-<) but doesn't work.
> 
> ... which brings me back to trying a simple QAction::setShortcut first.

A bunch of observations already, from a simple test thingy I had lying around, and reverting temporarily to Qt 5.6.2 :

// QKeySequence(Ctrl+Comma) doesn't work probably because normally owned by the system; doesn't show either.

    // shows as Shift-Command-, :
//     restoreAction->setShortcut(QKeySequence(Qt::CTRL + Qt::SHIFT + Qt::Key_Comma));
    // shows as Command-< :
//     restoreAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_Less));
    // shows as Shift-Command-1 :
//     restoreAction->setShortcut(QKeySequence(Qt::CTRL + Qt::SHIFT + Qt::Key_1));
    // shows as Command-! :
    restoreAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_Exclam));

It's probably to expected that Ctrl+Shift+1 is shown as such, and Ctrl+! as such too even if Qt could be aware of the kind of keyboard I have configured. In this pure Qt code they all work as expected provided I'm not trespassing on what is normally a system shortcut like Command+, (open Preferences) which doesn't even appear in the menu.

However:
- running the application with the XCB QPA still shows the shortcuts but none work. the SwapCtrlAndMeta attribute is unset with the XCB plugin, so shortcuts should function as on Linux/X11, and with KF5 applications they do when.

- In KF5 applications I have no problem redefining Command+; it will show in the menu, but will continue to perform the system action

- Important: Command+Shift+Letter shortcuts are not concerned, only shortcuts that include a "special" symbol which is accessible only under the shift.

- This also applies to Ctrl+Shift+Key shortcuts: Ctrl+! and Ctrl+< are just as dead as Command+! and Command+< . In KF5 applications but not in pure Qt.

- Adding some debug print probes in QNSView:keyDown: and QNSView:keyUp: I notice the following when defining a keycut with kxmlgui (the standard_actions KCM):

* press Ctrl[+Shift]+key, release key: keyDown event followed by keyUp event when I release <key>
* press Command[+Shift]+key, release key: only a keyDown event, no keyUp event.

Does kxmlgui shortcut recorder depend on keyUp/keyRelease events? If so, is there a way to monitor them (or where would I add a snooper without having to rewrite significant parts of unknown code? I'd add probes in Qt 5.6.2 but no longer have the build directory (and rebuilding would take hours).

I did reactivate Qt 5.6.2 and all the 5.29.0 frameworks that I had rebuilt against 5.7.1 . All frameworks were thus built against 5.6.2 .

This did NOT restore Command+Shift+Key functionality meaning that this particular regression was probably introduced between frameworks 5.27.0 and 5.29.0 .

What does work with 5.6.2 is Ctrl+Shift+Symbol (tested with Ctrl-< in Kate5). Going back to Qt 5.6.2 restored the regression.
I saved that shortcut to the default scheme so I could look at it, for instance:

<Action name="filetree_show_active_document" shortcut="Meta+,; Ctrl+<"/>

On Mac/Cocoa this corresponds to main "Ctrl+," and alt. "Command+<" (the difference was only to be sure how the comma is stored). The main shortcut works, the alternative doesn't.
I tried editing this to "Meta+Shift+,; Ctrl+Shift+,;", but kxmlgui converts that to to shortcuts "Ctrl+," and "Command+<" (sic!). The former works as such, the latter doesn't.

All in all I'm tempted to say that the regression lies mostly in KF5 and the way it interacts with Qt.

For now I'm converting my crucial concerned shortcuts to Ctrl+Command+Key because that works ...

R.