[Development] QAction-like API for QML

[Shawn Rutledge]

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.