[Development] Application wide shortcuts API for QML

[Rick Stockton]

On 12/11/2012 12:11 PM, Alan Alpert wrote:
> On Tue, Dec 11, 2012 at 10:56 AM, Mark <markg85 at gmail.com> wrote:
>> <little snip>
>> That sounds awesome :) Qt 5.1 material i guess?
> It gets in when it's ready. If it's quickly agreed to and easily
> implemented, it could get into 5.1.
>
>>> ...
>>> It wasn't explained well in the Actions API thread, but the thought
>>> was that this could be initially exposed with the Actions API. The
>>> string shortcut property there would be registered as an application
>>> global shortcut, so you could use Actions separate from any menus to
>>> do this. What do you think of having it just in the action API, or do
>>> you think it needs its own item?
>> If that is:
>> Item {
>>     KeyShortcut.shortcut: "ctrl+c"
>>     KeyShortcut.onTriggered: t.text = "ctrl c pressed"
>> }
>>
>> then i find the syntax rather long/complex for something fairly
>> simple. With that you need multiple Item { ... } to register multiple
>> application shortcuts so why bother making it look complicated if it
>> can look nice (and easier) as well. I am in fact using my syntax in my
>> project which looks like this: (an example with more keys can be seen
>> here [2]).
>>
>> Shortcut {
>>     key: "F5"
>>     onActivated: {
>>         console.log(key . " pressed")
>>     }
>> }
>>
>> That.. really depends.
>> Rick (added to cc) is working on shortcuts that work with keys and
>> mouse buttons. I don't know exactly how he's going to implement a
>> single class that can handle both keyboard shortcuts and mouse
>> shortcuts in a fashion like QKeySequence allows (for example:
>> QSomeSequence("CTRL + MOUSE_BUTTON_1")) That will have to be
>> coordinated with him so that the QML Shortcut class (however it's
>> going to look) won't be outdated as soon as it enters Qt.
> I would have thought that the goal would be to extend QKeySequence to
> accept 'mouse keys' as well. Then there would be no difference at all
> from the QML side.
>
> --
> Alan Alpert
>

Alan, I can't think of _good_ ways to extend QKeySequence into the thing
I'd like. As you know, we've had problems (some difficult) with even the
most simple 2-character keyboard sequences. And Backward Compatibility
issues, which I do not understand very well, are a problem if I change
the layout or length of the QKeySequence class, right?

A basic QKeySequence (not a standard key) contains up to 4
character-defining elements, each 32 bits long. For even the most basic
of mouse shortcuts, I need more than 64 bits as follows: 32 bits for
'button'; another 32 bits for held 'buttons'; plus some room for the
keyboard modifier flags, and maybe another field to distinguish Release
vs. DoubleClick. (And maybe more- ButtonPress, Press and Hold).

I want to allow an Activating 'signature' to include an immediately
following non-Modifier Key, but I'm not sure if this should be a
QKeySequence. In any case, I want the mouse event to be first; there can
be only one mouseevent; and the non-modifier keyboard matching (single
key or QKeySequence) happens immediately AFTER the mouse event has been
satisfied.

The matched mouse event must occur first- it "gates" testing of the
subsequent keypress (pressing of modifiers is to be ignored, they are
only "preparation" for the non-modifier key). Any intervening mouse
click closes the Gate, and any non-modifier keypress also closes the
Gate. But, while the Gate is "open", if the subsequent keypress event
matches the 'FollowingKeySequence' specified by the Shortcut, then the
shortcut is activated. Generally it will send a signal.

In this preliminary design, if you want to have a keyboard-only
QKeySequence AND a MouseSequence result in the same thing, you would
need to have separate QShortcuts and QMouseShortcuts (with or without
that optional 'FollowingKeySequence' specified) send a signal, and have
your resulting code executed from a connected Slot. Does this sound OK,
or even make sense?

-- 
GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A