[Development] QAction-like API for QML

[Alan Alpert]

On Tue, Dec 18, 2012 at 10:18 AM, Shawn Rutledge
<shawn.t.rutledge at gmail.com> wrote:
> On 18 December 2012 18:39, Alan Alpert <416365416c at gmail.com> wrote:
>> Used like Jens suggested for components:
>>> RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
>>> }}
>>>
>>> Granted, a bit too verbose. However with a little bit of convenience, we can
>>> for instance reduce this to just:  ActionRowLayout { model: myActions }
>>
>> Given this approach do we need the ActionGroup type? Are
>> exclusive/collapsible needed now?
>
> We discussed it in the office, and Jens made the point that if you
> need to expose a list of actions from C++ so that the QML can create a
> toolbar from them as described above, then it can just be a plain
> QList of actions.  (And putting all of the actions from an entire menu
> into a toolbar, to make basically a duplicate of one menu, is usually
> not good UI design anyway.)  Likewise making a tree structure to
> represent all the actions in the whole menu system may be the
> exception rather than the rule, and in any case it could be an
> external tree structure.  It doesn't actually make sense to call
> something an "action" if its only purpose is to contain other actions;
> it would be the action that doesn't act.  Likewise the exclusive group
> can be a separate thing, but we still have to decide how exactly to
> implement it.
>
> So now it seems to me that we can get rid of exclusive and
> collapsible, so as to simplify what goes into action so that we can
> get it implemented, and then continue thinking about the best way to
> expose collections of them from C++, or expose individual ones, as
> well as create them in QML.

Okay, forget about ActionGroup as a type for now. We can group them
with other methods in QML as well.

> But I still think the action needs a name, which can be used by the
> image provider to find the icon.  (This is independent of whether the
> image provider uses files or resources; the icon will be found by name
> either way.)  Maybe we can reuse objectName for that.  So the action
> is just called "open" but the image provider can go looking for
> icon-open-action.png or something, using its own naming convention.
> The point of that is to avoid repeating yourself in QML.

objectName has its uses, don't just give it an extra meaning. I see no
problem with adding a separate actionName or name property if that's
helpful, despite the presence of objectName.

> Whether the images are provided by a QIcon, or by some other means of
> providing multiple images at different resolutions, could also be a
> detail of the image provider.  So we can keep the action pretty well
> away from the View part of MVC: it's an abstract representation of one
> atom of the Control layer, not a visual representation, although it
> contains enough information to be able to construct a visual
> representation, so that you can stick it directly in a tool button or
> a menu item without having to add extra information first in your own
> QML.

How is this going to work? If no iconSource or imageSource exists on
the Action then the delegate in QtQuickControls uses
"image://icons/<action-name>.png"? Or would that be in the
QtQuickControls, that the delegate renders that url if no source is
found? While an image provider would be perfect for this, it would
probably have to go in QtQuickControls and then it can't be in the
Action type (unless this is a QtQuickControls specific Action type,
which I don't think is a good idea).

>
> The explicit properties that we put into the C++ implementation of the
> action class can be limited to the ones that we know every component
> implementation will need, as long as we can still add dynamic
> properties (or new properties in subclasses) for the platforms that
> need something extra.

Of course. I think that's implicit in the Action type being a type for
QML instead of specifically for QtQuickControls.

--
Alan Alpert