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, Иван Комиссаров <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
