[Development] Application wide shortcuts API for QML

[Alan Alpert]

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

Doesn't sound like much of a corner case to me. Actions aren't
strictly visual, but I can see why they might not be conceptually
linked for everyone. A Shortcut{}  API (with a strict subset of
Action{}) might make sense to provide just for convenience and
performance. Especially if the implementation virtually falls out of
the Action stuff.

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

A safe choice, but keep in mind that the people who do know how that
stuff works are extremely busy ;) .

--
Alan Alpert