[Development] QAction-like API for QML

[Bache-Wiig Jens]

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

Action has clear semantics in Qt. It is a GUI concept to describe properties that belong in a specific implementation of a UI. What you are proposing should not be called CoreAction as it has nothing todo with QAction. You are proposing a new concept to Qt. I still find it redundant since it is trivial to implement yourself,  but if your backend needs a signal that can be disabled I would suggest that we introduce it as a different class called QTrigger and keep it outside of this discussion.

If you have doubts that Action is a GUI concept, take a  look at the properties:
autoRepeat, checkable, checked, enabled, font, icon, iconText, iconVisibleInMenu, menuRole, priority, shortcut, shortcutContext, softKeyRole, statusTip, text, toolTip, visible, whatsThis. How many of those belong in a backend? How many can you reuse in both mobile and desktop UI's?

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

So you redeclare your Actions in your fronted and somehow associate them with CoreAction?

QGuiAction openAction(Core::openCoreAction):
openAction.setShortcut(); 
openAction.setIcon()
openAction.setToolTip, setEtc…

Again, I gain nothing from this apart from having to declare all my actions twice. Though if the concept is worth implementing we can alway add a setTrigger function to QGuiAction in the future.

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

No it does not. QtWidgets is in a separate library. We will put the new C++ class in QtGui and expose it to QtQuick. This would then be just as available to widgets as it is in QtQuick. But I am not a sure how much effort we should use to make it usable in widgets. I would like it to be optimised for QtQuick. QAction already works great for widgets. Making QQuick also support QAction seems more important to existing users.

Jens