[Development] Application wide shortcuts API for QML

[Mark]

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

Ahh right, so i'm mixing things up :p
Sorry for that.
>
>> 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).

In my opinion it certainly needs to be separated. Here is my usecase
why i think that way.
Right now i'm building a file manager application in QML (it looks
awesome and a lot like [1] though less windows 8 like) In that
application i need to have some application wide shortcuts (which i
why i'm in this mess to to begin with).

I for example need:
F5 (refresh)
Cut
Copy
Paste
Delete
...

The standard shortcuts for file management. "some" of those shortcuts
will have a visible manner as in a button and in those situations a
"QAction" (Action) object would be OK. Some other shortcuts are just
that, shortcuts. For example, if the user starts typing in file
overview a search form will pop up in which the typed stuff will
appear. That form is an action that doesn't have a button or anything.
It's just a key binding to "show" a certain QML part. So yes, a plain
"Shortcut{}" does have value to me. But i might have a special corner
case here.
>
>
>>
>> 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.

I'd like to, but i have far to little knowledge about programming to
get something like that working. I kindly skip that and pass it on to
people that do know how that stuff works.
>
> --
> Alan Alpert

[1] http://img254.imageshack.us/img254/4174/explorer3.jpg