[Development] QAction-like API for QML

[Bache-Wiig Jens]

>> 
>> What is so terrible about it? QtWidgetEnables would be private API, only used by components internally and we would not need to load the module on embedded, or am I missing something?
> 
> I don't see how you'd avoid loading the module on embedded. Because
> the components are written in QML you'd need the QtWidgetEnablers
> plugin available at runtime for any application using the components
> (assuming they include an import QtWidgetEnablers 1.0 line). I also
> don't know how you'd write the C++ module to avoid having a
> libQt5Widgets runtime dependency.

Well we have the same issue with components so we really have to find a solution if we have any plans of making those widget independent in the future. Embedded would be fine regardless since you could still ifdef QT_NO_WIDGETS from your qtbuild before deployment.

> The only dynamic inclusion approach I can think of is to have
> QtWidgetEnablers contain another version of Menu {}, which can be used
> like a Menu{} in components but shich can also accept QAction*s. Then
> the extra module is loaded only by components users wanting to use
> QActions.

That was what I had in mind. It is essentially what we are doing with QStyleItem at the moment, so I was thinking we could do the same for IconItem as well. I was working under the assumption that it would be ok to just expose the actions as a context properties so I did not see the problem using this approach. We would not expose IconItem directly in the API but use them internally in the button delegates.

>> ename the element MyActionGroup{} and it suddenly makes perfect
> sense. Although it's still abstracted to such a degree that it doesn't
> cover the question of whether menu and toolbar action groups normally
> coincide.

Yes. This API could have worked ok for classic widget apps where a toolbar is essentially just a collection of actions.

What was/is being proposed is that I should reduce the ToolBar to this:
toolBar: ToolBar {MyActionGroup{}}

That works only for classic widgets where toolBars are just a flat collection of icons.
What QML-style application development encourages is to break free from those boundaries and construct something like this: http://i.imgur.com/R5Xhz.png

To do that, I need an api where I can construct a ToolBar from QML primitives. The above approach is simply not flexible enough for that. Even if you add a ton of hints.

I would prefer: toolBar: ToolBar { {ToolButton { action: copyAction} TextField { .. } etc }

Jens