[Development] Move QAction from QtWidgets to QtGui

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120703/35c650b7/attachment.html>