On 16 December 2012 15:32, Bache-Wiig Jens <jens.bache-w...@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.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
