[Development] Move QAction from QtWidgets to QtGui

[Alan Alpert]

There was a general agreement to add QGuiAction in a previous thread
on the dev list (Integrating QAction and the upcoming QML Action).
It's just that work on it hasn't started yet, if you want to
contribute you could see it done faster :) .

As for the API of QGuiAction I got the impression it was to be the
minimal shared subset between QAction and the QML Action (added to
desktop components first,
https://codereview.qt-project.org/#patch,sidebyside,44418,2,src/qtdesktop/qtaction_p.h,
 but might move around). You don't need to move the functionality
around like with the associatedObjects function, because anyone who
wants the old functionality with widgets has no problem still using
QAction for their widget code. The important part is that QAction
becomes a wrapper (either subclass or containing one) around
QGuiAction so that QML and Widgets code can share the same QGuiAction
instance.

--
Alan Alpert

On Sun, Jan 13, 2013 at 7:10 AM, Иван Комиссаров <abbapoh at gmail.com> wrote:
> Sorry for reanimating old thread:)
>
> I was looking at QAction code and didn't see big dependecies on qtwidgets.
>
> Isn't possible to implement this solution, keeping source and binary compatibility:
>
> We add QGuiAction to QtGui module. It has exact API like current QAction (which is discussable, but it's not my main idea) except it doesn't have associatedWidgets method. Instead, it have assotiatedObjects method and stores abstract QObjects (which are QWidgets, QGraphicsWidgets or QML items).
>
> QAction becomes a simple wrapper around QGuiAction and adds associatedWidgets method which looks like this:
>
> QList<QWidget*> associatedWidgets()
> {
>      QList<QWidget*> result;
>      foreach (QObject *object, assotiatedObjects()) {
>           if (QWidget *w = qobject_cast<QWidget *>(object) )
>               result.append(w);
>      }
>      return result;
> }
>
> The next thing to fix - is ~QAction(), it should remove itself from added objects.
> I suggest to use destroyed(QObject*) signal and move that code into the QWidget itself.
> Second solution is to send RemoveAction event to objects.
> Third solution requires RTTI - we can add c++ interface to a QWidgetPrivate that allows to remove actions from it and use dynamic_cast to cast object's d_ptr to that interface (hack, yeah)
>
> I prefer signal, anyway - it' widget's problems to track objects it refers too. And in most cases QWidgets becomes deleted before it's Actions.
>
> Advantages - current code keeps working, no breaking compatibility we can write code that is not dependent on the QWidgets and share between qml/widgets code.
> Disadvantages - QAction will work a bit slower.
>
> Иван Комиссаров
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development