Op 18-12-2012 20:34, Shawn Rutledge schreef: > On 18 December 2012 20:05, Mark <mark...@gmail.com> wrote: >> On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert <4163654...@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é _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
