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

[André Somers]

Op 18-12-2012 20:34, Shawn Rutledge schreef:
> On 18 December 2012 20:05, Mark <markg85 at gmail.com> wrote:
>> On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert <416365416c at gmail.com> wrote:
>>> D) QCoreAction is added to Core or Gui and has even less
>>> functionality, QQuickAction and QAction/QGuiAction build on top of
>>> that to fill out their API.
>> Another option.
>>
>> Create a QAbstractAction with the bare minimum that is QML and QWidget
>> independent.
>> QQuickAction on top of QAbstractAction to implement the QML specifics.
>> QAction also on top of QAbstractAction for the QWidget module. Or just
>> leave the QAction in there as it is since it's "completed" anyway.
> How is that different than D?
>
> Having a base class would at least give us the chance to reparent
> QAction to inherit from it in Qt 6; isn't that the only advantage?
I don't see why QAction needs to inherit from a QCoreAction, and why 
that would be an advantage. It could simply encapsulate one. If you 
don't assing one manually, it just owns a default constructed one, so 
there is no need to use QCoreAction explicitly if you don't want to. 
Same goes for a QML variant.

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. I've 
been in places where the policy was even to not use Qt at all there, but 
not using QtGUI and above in core libs is almost a given. Having a 
QCoreAction to expose functions that can be wrapped at the GUI level 
with all the stuff the core doesn't want to know about (icons, 
shortcuts, help texts, etc.) would be very, very helpful in such cases. 
I think that QAction could be retrofitted to use such a QCoreAction.

André