[Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)

[Alan Alpert]

On Wed, Dec 19, 2012 at 5:06 AM, André Somers <andre at familiesomers.nl> wrote:
> Op 19-12-2012 12:46, Stephen Kelly schreef:
>> On Wednesday, December 19, 2012 08:57:31 André Somers wrote:
>>
>>> My preference is D, obviously. I think it makes a lot of sense to be
>>> able to use actions in core, non-GUI layers of the application.
>> Qt is primarily for creating Guis. I sympathise with the desire to use Action
>> API in a 'core only' API without linking to QtGui or QtWidgets, but it's not
>> what we should optimise for.
>>
>> Maybe it's something we can design for in Qt 6, but for now, focusing on
>> solving problems in UI development should be reflected in our API and design
>> choices. I'm thinking mostly about keeping QIcon, QKeySequence etc in the API.
>>
> I'm not too sure about your claim that Qt is primarily for creating
> Guis. That might have been the case when is was still "just" a widget
> library, but that has been a long, long time ago. Now, it offers many,
> many very useful tools for all layers of the application. But that
> doesn't mean you want to link against a GUI lib from a core layer in an
> application.
>
> Last attempt on this topic though:
>
> The nice thing about this (D) proposal is, that it can be done now
> (5.1), and it won't need new changes in actions for 6.0.
>
> class QCoreAction: public QObject
> {
>      Q_PROPERTY (bool enabled READ enabled WRITE setEnabled NOTIFY
> enabledChanged)
>
>      Q_SLOT trigger();
>      Q_SIGNAL triggered();
>
>      // and the property getters, setters and notifies above
> }
>
> though, it should probably keep the checked stuff as well:
> class QCoreAction: public QObject
> {
>      Q_PROPERTY (bool enabled READ enabled WRITE setEnabled NOTIFY
> enabledChanged)
>      Q_PROPERTY (bool checkable READ isCheckable WRITE setCheckable
> NOTIFY checkableChanged)
>      Q_PROPERTY (bool checked READ isChecked WRITE setChecked NOTIFY
> checkedChanged)
>
> public:
>      QCoreAction(QObject* parent);
>
>      Q_SLOT trigger();
>      Q_SLOT toggle();
>      Q_SIGNAL triggered(bool checked = false);
>      Q_SIGNAL toggled(bool checked);
> }
>
> Very simple. Now, take the existing QAction, and add:
>
> class QAction: public QObject
> {
> public:
>     QAction(QCoreAction* coreAction, const QString& text, QObject* parent);
>     QAction(QCoreAction* coreAction, const QIcon& icon, const QString&
> text, QObject* parent);
>
>     QCoreAction* coreAction() const;
>     void setCoreAction(QCoreAction* coreAction);
> }
>
> QAction would just use an internally constructed QCoreAction if none is
> set explicitly. QAction would basically simply connect to the
> QCoreAction's signals and slots. QAction can then both be used as-is, as
> well as with explicitly created QCoreActions.
>
> QGuiAction can work in the same way.
>
> I think a design like this has the following benefits:
> * compatible with current Qt, no need to wait for Qt 6 for any of it. Qt
> 5.1 would work.
> * Makes the action concept usable in core application libraries that are
> restricted to linking against widget libs
> * Keep QAction usable in the same way it is now
> * Doesn't bind QML to QtWidgets or vise versa
> * Legacy code can be used for binding with QML as well, because
> QCoreAction will be created implicitly by QAction without special work
> to be done for that bridge. All you need to do is share the coreAction
> instance.

I like those benefits, but I think it should be named QGuiAction and
go into QtGui. Actions are inherently UI specific, and while not
necessarily graphical I don't think they're too helpful for a CLI Qt
App. I've also heard that QtCore is supposed to be kept small - not
all non-gui stuff gets in there or else we'd need a separate QtKernel
for the actual minimal core set.

So this suggests that QGuiAction goes into Gui, QAction stays in
Widgets and gains the bridge that Andre suggested. The difference
between C) and D) (the clear favorites so far) is whether QGuiAction
gains the QML API of properties and such, or whether an additional
QQuickAction is added. I'm still in favor of C), where QQuickAction
(as a GUI primitive) is just directly exposing the QML API of
QGuiAction. Can anyone think of a reason we'd need the separate class?

--
Alan Alpert