[Development] Application wide shortcuts API for QML

Alan Alpert 416365416c at gmail.com
Tue Dec 11 21:50:20 CET 2012


On Tue, Dec 11, 2012 at 12:29 PM, Mark <markg85 at gmail.com> wrote:
> 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.
>> ...
>> 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.

Actually, it is. I'm talking about the same Action API, it just
happens that one of its properties is a shortcut and so you can also
use it for global shortcut functionality.

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

Not really. QAction's shortcut property doesn't take a QShortcut. It
takes a QKeySequence. Which is correct, because it's a lot easier to
write and leads to a more convenient QML API for Action. So even if
there were separate Shortcut and Action types in QML, they'd be used
like this:

Shortcut {
  shortcut: "CTRL+C"
  onTriggered: foo();
}

Action {
  shortcut: "CTRL+C"
  onTriggered: foo();
}

Which is why I'm wondering whether the Shortcut type needs to exists separately.

But this is the exact same Action type as in the other thread,
including much of the functionality of QAction, so it's possible that
there should be a separate Shortcut{} element for people who don't
want all that extra functionality to get in their way. I can't think
of a usecase where it would be a problem, and where you wouldn't want
the action capabilities as well, but if such a usecase existed then
maybe we'd want a Shortcut{} with just the one property and one signal
instead of the Action{} with a dozen properties and signals (even
though you only use one property and one signal).


>
> 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.

I agree it sucks, but there is no real way to expose arbitrary C++
enums to QML. If QKeySequence inherited QObject then it might work,
but without that we can't expose the type to QML. If you want to fix
Q_ENUMS so that it can apply to inherited enums of the non-QObject
superclass (but still only in a QObject class declaration) that might
make sense.

--
Alan Alpert



More information about the Development mailing list