[Development] QAction-like API for QML

[Alan Alpert]

On Sun, Dec 16, 2012 at 4:38 PM, Bache-Wiig Jens
<Jens.Bache-Wiig at digia.com> wrote:
>>>
>>> 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.

I thought the plan was to get away from all widget dependencies in the
component set ASAP. The idea was that anything the component set
needed which was still in widgets (but not widget-specific) would get
abstracted out of widgets. This is the whole point of the discussion
over a new QAction-like API for QML, so that components don't have a
widget dependency.

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

Okay, we're not discussing the ToolBar API here (I'm happy to leave
that to you) save for the implications for an 'action' property. If
another wrapper item is needed then that's fine, the question then is
what still will be needed from the Action type.

--
Alan Alpert