[Development] Application wide shortcuts API for QML

[Alan Alpert]

On Tue, Dec 11, 2012 at 10:56 AM, Mark <markg85 at gmail.com> wrote:
> On Tue, Dec 11, 2012 at 5:12 PM, Alan Alpert <416365416c at gmail.com> wrote:
>> On Tue, Dec 11, 2012 at 12:53 AM, Mark <markg85 at gmail.com> wrote:
>>> Hi,
>>>
>>> Alan' posts about possible future APIs made me want to post this as
>>> well. In the QWidget works we have the rather nice QShortcut class to
>>> aid us in defining application wide shortcuts.
>>>
>>> Functionality like that is completely missing from the current QtQuick
>>> in both Qt 4.8 (1.1) and 5.0 (2.0). For desktop based applications an
>>> API like that would be very much needed since applications need to
>>> have the ability to define app wide shortcuts.
>>
>> Known issue. In fact, someone already started work on this:
>> https://codereview.qt-project.org/#change,41816
>
> 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")
>     }
> }
>

It wasn't explained well in the gerrit comments, but we agreed the
attached property notation was overly cumbersome as well. In fact,
that change should probably be abandoned I just wanted to show that
people have been working on it.

The actual place the proposed API is at is to implement it in the new
Action API, which has it's own thread. For just the shortcut case it
would look like this:

Action {
    shortcut: "F5"
    onActivated: {
        console.log(shortcut . " pressed")
    }
}

Which is extremely similar to your API. So my question is, do you
think that it needs to be a separate type, like Shortcut{}, or would
it be just as good to use the Action type?

> What i wanted to add was the ability to also do (ability to use the
> StandardKey enum. I couldn't get the darn enum to work in QML without
> copying it to my class):
> Shortcut {
>     key: QKeySequence.Refresh
> }

Sadly, this is the current solution for exposing enums to QML. You
need to copy them to your class.

>
> and to get mouse shortcuts available
> Shortcut {
>     key: "CTRL + MOUSE_BUTTON_1"
> }
>
> Or perhaps slightly different to really differentiate mouse "buttons"
> and keyboard "keys" like so:
> Shortcut {
>     key: "CTRL" // keyboard key
>     button: "MOUSE_BUTTON_1" // mouse button
> }
>
>
>>
>>> Obviously if this is going to happen then mouse shortcuts should be
>>> included as well. Right now Qt itself has no possibility of defining a
>>> shortcut like "CTRL + LEFT MOUSE BUTTON" (or i don't know of it's
>>> possibility).
>>
>> I agree that functionality would be nice to see for shortcuts in Qt.
>> But it's probably a separate issue, distinct from exposing the current
>> functionality to QML (which is a logical first step).
>
> 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