[Development] QAction-like API for QML

Shawn Rutledge shawn.t.rutledge at gmail.com
Sun Dec 16 16:55:23 CET 2012

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?

> 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.
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.

> When you want to re-use a menu, I would argue the appropriate abstraction would be to make a QMenu subclass using a subset of actions. An action group should not be assumed to be a menu since it can be used in any context.

You 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?

> Similarly in QML, I would create a Menu component and re-use that. When I use the same actions in a toolbar I would anyway have to re-order and handpick the ones that make sense in that context.

Sometimes but not always.

> 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 }

to create one toolbar for each menu.  And each action's visibility
bitfield could control whether it shows up in the toolbar or not.

> I would prefer: MenuBar { EditMenu { } } where EditMenu is a carefully crafted Menu, built using a subset of actions.

Except that the menubar probably has more menus.  But yeah, you could
do that too, if you really need to customize it.

> 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?
> 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.

More information about the Development mailing list