On 16 December 2012 20:05, Bache-Wiig Jens <[email protected]> wrote:
> On Dec 16, 2012, at 4:55 PM, Shawn Rutledge <[email protected]>
> 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.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
