[Development] QAction-like API for QML

[Shawn Rutledge]

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.

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.

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.

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.

> I'm of the opinion that Shortcut{} is just confusing, it adds the
> cognitive load of having a choice on how to implement a shortcut for
> no good reason.

That I agreed with from the beginning; I don't see a point in having
anonymous shortcuts, because they should usually be in the menus so
that users can find them.  Even if you disagree, you can still create
an action and then leave it out of the menus; we just have to ensure
that the shortcut works whenever the action is enabled.