[Development] Application wide shortcuts API for QML

[Mark]

On Tue, Dec 11, 2012 at 9:11 PM, Alan Alpert <416365416c at gmail.com> wrote:
> 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.

Nice :)
>
>>> ...
>>> 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.

Nice as well!
>
> 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")
>     }
> }

Hmm.. So this is actually just about Shortcut or Action. In this case
i would say Shortcut is the better name. Not because i made it up, but
because it's exactly that. A shortcut. It can "do" an action, but it
isn't an action.

Also, people will certainly get confused by thinking that the QML
Action type would be the QAction version of QML. Something that is
certainly not true. I think Action can be better used to serve as a
QAction for QML like in one of the other threads you created.

And for the Action type to register a shortcut it would "probably"
look somewhat like this then:
Action{
    shortcut: Shortcut {
        shortcut: "CTRL+C"
        onTr... you get the point
    }
}

In this case it looks odd, but think of it like this:
Shortcut { // For clarity, a QML version of QShortcut
    id: copyShortcut
    shortcut: "CTRL+C"
    onTr... you get the point
}
Action{ // For clarity, a QML version of QAction)
    shortcut: copyShortcut
}

Nice, clean and easy to understand in my opinion :)

As for the "shortcut" property, that's fine. I think it's even better
then "key" since it's independent of the "key" type ("key"board and
mouse"button").
>
> 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?

Funny because i never saw it :) I just followed the QShortcut logic, hehehe
>
>> 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.

That really sucks! Is there any intention on supporting that in Qt
5.1? Would be very convenient.
>
>>
>> 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