[Development] Application wide shortcuts API for QML

Shawn Rutledge shawn.t.rutledge at gmail.com
Tue Dec 11 23:28:40 CET 2012

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.

More information about the Development mailing list