[Development] QAction-like API for QML

[André Somers]

Op 14-12-2012 8:45, Bache-Wiig Jens schreef:
> I have been lurking in the discussion a bit but I guess it is time for me to pitch in. It is hard to keep up with 10 different threads at once. :)
>
> I find the idea of adding a new QCoreAction base class that is shared between QML Action and QAction and only carries a small subset of properties an unnecessary layer of abstraction. The idea of QAction is to have the convenience of icons, text and shortcuts predefined for you in a shared location. If you remove most of those properties, you anyway have to redefine the shortcuts and icon every time you use them and quite frankly I see no added benefit of this core action class that I cannot cover by simply having a shared signal that my MenuItem connects to.
Well, I disagree with that view of what an action represents. To me, the 
core of an action really is bundling a bit of state with a trigger for 
something to happen (I try to avoid the word 'action' here) in a 
convenient API. That piece of state includes at minimum if that action 
is available right now, and can also contain a value ('checked' is the 
value that QAction can currently carry, so basically a boolean). That by 
itself is already a very useful thing to have, as it provides a very 
nice and clean way to expose functions on an API, especially for code in 
a core layer of the application.

You claim that you'd have to "redefine" the shortcuts and other GUI 
related properties every time you use the (core) action. Why so? Your 
GUI layer can simply get these core actions and re-expose them once, 
right? At the moment, you frequently see methods that are responsible 
for creating all the actions in the application. You'd have the same, 
only instead of having to manage multiple connections to keep track of 
state in the core and the action that represents that, you set a 
coreAction on the action and have that part taken care of. Then, you set 
the QAction you created on your toolbar, your menu and whatever else you 
fancy.

The benefit is in the way that you bundle the relevant bit of state, a 
handle to an action and a value into one convenient abstraction. Instead 
of having to expose and connect to these separately to keep your GUI 
consistent with application state, you only need to reference a single 
object. And that single object can be used both in the widget world as 
well as in the QML world. At the same time, if you like.


> What I would propose is that we keep the QAction exactly as it is and make it possible to use it from QML as well as introduce a new slightly simplified QML Action component as previously suggested. The only drawback to this approach is that actions you declare in QML won't be immediately usable from C++, but I don't see this as a big issue. You will either keep everything in QML or have your business logic including your QActions defined in in C++.
As mentioned by others, this would mean that any C++ core that you write 
would *have* to pull in QtWidgets in order to be able to use actions. 
Even if you only have a QML gui. Not very attractive, if you ask me.

André