[Development] Move QAction from QtWidgets to QtGui

simon.hausmann at nokia.com simon.hausmann at nokia.com
Tue Jul 3 18:45:06 CEST 2012


I'm not a fan of moving QAction back to QtGui, because there it would be a class that cannot be used by itself. Out of the box it is only useful with the containers in QtWidgets.

I understand that you can theoretically use it just as property bag, but I don't think that would be a common pattern in Qt.

Simon

--
Sendt fra min Nokia N904.07.12 00:20 skrev ext Charley Bay:
> How would you suggest solving it?  QAction does have stuff like
>
>      bool showStatusText(QWidget *widget=0);
>      QWidget *parentWidget() const;
>      QList<QWidget *> associatedWidgets() const;
>      friend class QWidget;
>
> so it seems difficult to make it avoid depending on widgets without breaking
> API compatibility, which is why I figured we would need a separate Qt Quick
> action class.  Do you have any better ideas?

 
André respondeth:
Would it not be possible to split QAction in two classes, just like
QApplication was split? We could perhaps create a QCoreAction, that has
no GUI dependencies at all but just has the core functionality:
representing an action, a way to trigger that action, and the state of
that action. Things dependent on QtWidgets could stay in QAction itself,
which would probably subclass QCoreAction. QAction would stay in
QtWidgets, but QCoreAction could live in QtGui or even QtCore.

Having an action class that is independent of GUI-like things like icons
would be great to have for C++ as well. It makes it less awkward to use
Q(Core)Action's in business-layer objects to expose functionality. The
GUI layer could simply wrap these actions then and only add the
GUI-dependent properties like icons.


+1 from me.


We would use "QCoreAction" (in our domain, lots of business-model internals, hardware device interfaces, etc.)  We *cannot* link GUI things into our embedded control-systems.


Because we don't have that, we create our own "Functor-like" classes that do what "QCoreAction" would do if it existed.


Good call on past design decisions to break-out "QCoreApplication".  Multi-threaded command-line utilities implemented using Qt on the "back-end" are awesome.


--charley



More information about the Development mailing list