[Development] Application wide shortcuts API for QML

[Mark]

On Tue, Dec 11, 2012 at 11:28 PM, Shawn Rutledge
<shawn.t.rutledge at gmail.com> wrote:
> On 11 December 2012 22:11, Mark <markg85 at gmail.com> wrote:
>> 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.
>
> What's wrong with making an action anyway, and just not putting it
> into any graphical object?  Like I wrote in the other thread, I think
> it's important for the tree of Actions to be independent from the gui.
>  The tree can structure the application's menu system, regardless what
> form that might take (traditional desktop menubar, ipod-style sliding
> drill-down, expanding outline, etc.)  And it's important that if you
> associate the same action with multiple components, that if you
> disable the action they all get disabled.  And you might want to
> instantiate the Actions in C++ and expose them to QML.  Therefore it
> doesn't make sense to instantiate an action inside of a MenuItem or
> Button; the action tree needs to exist separately, and then you assign
> the action to the button by ID.  We could further specify that the
> event filtering for the shortcut takes effect as soon as the Action is
> created, right?  The constructor could add it to an internal list of
> shortcuts which the filter looks for.  (But I suppose a disabled
> action has a disabled shortcut too.)  Then if you change your mind
> later and want to make the action visible in a button or menu item,
> it's easy.
>
> The Action object should be lightweight.  If you only need a shortcut,
> then it should be enough to give the action an ID and the shortcut key
> specification, and leave everything else blank.

I'm fine with both. Just a Shortcut{} and a Action{} would be my
preference, but the way you describe it with only a Action{} would
work equally well.