> > > 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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
