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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
