[Development] QAction-like API for QML

[André Somers]

Op 11-12-2012 4:39, Alan Alpert schreef:
> QAction served widgets well as an abstraction for an "Action" which is
> exposed to the UI in a platform specific manner. This was shared
> between menus and toolbars and some other things. I think we'll need
> something similar for QML, so that the QtQuick controls can provide
> platform styled menus, toolbars, and perhaps some other things. This
> is particularly important for those working on the modern
> cross-platform challenge of scaling to different devices - we need the
> actions generic enough to fit a phone's itty bitty little menu as well
> as the unifed menubar that spans over 2000px on today's Macs.
Please note that there have been earlier discussions on this, also 
discussing ways to share a common base between QAction and some QML 
equivalent.
> Note that it has no-where near as many properties as QAction. toolTip
> and whatsThis for example are very desktop centric so not needed
> anymore. Because it's not actually doing the rendering it doesn't need
> enabled, visible or font. As for the rest I think it's better to start
> with the minimal essentials and add stuff later if it's needed. I'm on
> the fence about whether checkable needs to be in the first version
> even, I can't recall the last time I actually saw a checkable menu
> item.
Well, I think that's where you go wrong already. Enabled *is* a very 
useful property to have, even if you use the action only as an abstract 
representation. At least, I use QAction in some non-gui code where the 
base properties like the enabled flag are manipulated as the 
availability of an action changes due to state changes in the 
application. At that level, I really don't care about how that is 
represented, but I do care that I have one unified object to represent 
the action.

That action object for me, at the very basis, represents a handle to 
trigger the action and tells me about its availability. The action would 
be void action: taking no arguments. But the enabled property belongs in 
there.

Just above that, it may need something like a value. The current QAction 
has that in the form of the checked property. It is basically restricted 
to a single type of value with that, but I don't think that that is by 
defintion the only useful value an action could have. On the other hand: 
by far not all actions actually _need_ any value, boolean or not.

Above that, the action may need a representation in the GUI, and that 
results in a name, visibility, an icon, a tooltip, etc. This is where 
the real differentation between the Widget and QML worlds would occur, I 
think. For instance the way images are handled are very different, using 
QPixmap, QIcon or QImage in the widget world, and using a URL in the QML 
world. And, indeed, some things like tooltips probably don't make sense 
in the (primarily touch-oriented) QML world, while they are a must on 
the desktop.

Grouping, IMHO, belongs on that top level as well.

I don't know what the best realization of something like the above might 
be, but you might want to considder it in your quest to give QML actions 
as well. I think at least that part of the reasoning: that the concept 
is useful in QML as well, is very sound.

André