[Development] QAction-like API for QML

[Bache-Wiig Jens]

On Dec 16, 2012, at 4:55 PM, Shawn Rutledge <shawn.t.rutledge at gmail.com> wrote:

> On 16 December 2012 15:32, Bache-Wiig Jens <Jens.Bache-Wiig at digia.com> wrote:
>> I did not say the idea was not useful. My point was that it is not required since we already have access to everything the common base class would give you. Action is a QObject, so when we expose it to QML, we can already access text, toolTip, statusTip, triggered and all of those core properties even without sharing the implementation.
> 
> 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.

You can for instance do something like this:

QAction *act = new QAction(...);
qmlview.rootContext()->setContextProperty("fileAction", act);

>> But QAction and collapsible groups is not the right abstraction for this. First of all it means nothing in QToolBar. (what is a collapsed group or sub-menu doing there?)
> 
> 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.

> An action could have a visibility bitfield, which specifies where it's
> visible and where it isn't, so that you can have menus which are more
> complete than the toolbars.  And we should also not preclude building
> up a toolbar from individual actions, in case the app author wants to
> rearrange the order, or wants to allow the user to customize the
> toolbar.  But even an action with a submenu could potentially pop up a
> menu if used on the toolbar.  Undo/redo buttons and forward/back
> buttons often have optional drop-down menus.

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. 

> ou don't need to assume it when creating the action group, but if
> everything is there in the right order already, why do you need to
> re-declare what goes into the menu?

Because they are different concepts. There is no addActionGroup() in QMenu or QToolBar either. You are proposing a new API that is not compatible with the concepts we have in widgets already and I fail to see why it's an improvement. 

>> As I said I don't think ActionGroup is the correct abstraction. You are already treating it as if it was a menu. If it was, then you should be able to put it in a ToolBar as well. How meaningful is this:  ToolBar { MyMenuGroup{} }
> 
> Instead maybe you could do
> 
> Repeater {
>  model: MyMenuGroup { }
>  Toolbar { modelData }
> }

That would be incorrect syntax. You are creating a ToolBar for each Action. 

A more appropriate syntax would be:

ToolBar {
    Repeater { 
        model:  MyMenuGroup {}
        ToolButton { action: modelData }
    }
}

Which happens to be exactly what I proposed. :)

>> Remember that the iconSource can use any image loader. I already did an icon-name loader in the qt4 branch to provide support for logical icon names such as iconSource: "image://desktopicon/edit-copy" }".
> 
> 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.

>> 
>> To ease up the syntax i also added an "iconName" convenience function to Button, ToolButton and MenuItem. I haven't yet added this in the qt5 branch yet as it still depends on widgets.
> 
> 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. This is why it is problematic to design QAction around the concept. I wouldn't really mind if we added iconName to QAction though.

Regards,
Jens