[Development] QAction-like API for QML

Shawn Rutledge shawn.t.rutledge at gmail.com
Sun Dec 16 21:19:33 CET 2012

On 16 December 2012 20:05, Bache-Wiig Jens <Jens.Bache-Wiig at digia.com> wrote:
> On Dec 16, 2012, at 4:55 PM, Shawn Rutledge <shawn.t.rutledge at gmail.com> wrote:
>> How can you expose it without needing to link to the widgets library?
>> or without sharing implementation?
> Your C++ application adds it's widget actions to the root context. Your application links against widgets but the declarative itself module doesn't have to.

But if you are writing a 100% declarative UI you'd probably wish to
avoid linking against widgets.  So I guess you're saying regular old
QActions should be exposed just for putting a declarative UI onto
legacy apps, and also there should be a new QQuick action, which is an
unrelated class?

>> Well a single menu with no submenus could populate a toolbar.  In a
>> desktop app which has multiple toolbars, usually the same grouping is
>> used: functions from the edit menu are put onto an edit toolbar, etc.
> I strongly disagree and your edit menu example is actually underlining my point.  I get annoyed whenever I see copy, cut and paste placed on a ToolBar. This is a beginner mistake for application developers. Novice users discover these by reading menus and power users know their global key shortcuts already. The ToolBar should be for actions that are application-specific, common and not easy to memorise such as "Send", "Reply and "Attach". In a modern and clean UI you will find a lot less actions on the ToolBar than in the menu, and the API should reflect this.

That's a good point.  I don't use the toolbar in those applications,
when it's just full of those actions that have well-known shortcuts;
sometimes I get rid of it.  But I've seen some people using them too;
not sure why.

The action could still specify whether or not it's toolbar-worthy though.

> I know that we can _force_ QML ActionGroup into becoming a visual description of a Menu but I don't get why that is a god idea. Menu is already an abstraction designed to describe a menu. Remember that in widgets, QActionGroup as a concept that is more similar to what we called CheckableGroup on Meego components. It does not at all indicate proximity or visual representation.

Then I guess you don't place much value on reducing verbosity in QML.
If you create the actions in C++, you'd still have to repeat each and
every one in QML, unless we provide a way to iterate over the ones
that should be in a menu, or a toolbar.  Yes repeating them gives you
a chance to pick and choose, or customize them, but I hope it can be
avoided in the simple cases.

>> Repeater {
>>  model: MyMenuGroup { }
>>  Toolbar { modelData }
>> }
> That would be incorrect syntax. You are creating a ToolBar for each Action.

No, MyMenuGroup is a group of groups, not a group of actions.  So one
toolbar for each major category.

>> What about loading a different size in the menu item than in the toolbar?
> An image provider can actually provide pixmaps at any size. If the ToolBar requests a 24 pixel icons and the MenuItem requests 16, it is up to the image provider to provide the appropriate sized icon.

Sounds good.

>> IMO it should be possible for the icon name to come from the action
>> rather than needing to be declared in the individual button or item.
> Sure. But we don't actually have support for logical icon names on Windows, Mac or Embedded since we don't have pixmaps for those.

I'm not sure what you mean.

More information about the Development mailing list