On Tuesday, July 03, 2012 16:45:06 [email protected] wrote: > 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.
What do you mean by containers? You mean QMenu etc? I don't understand that argument at all. It would be like saying (before starting the modularization and Qt 5 effort, and before QML) that QCursor should not be moved to QtGui because it is only used by Widgets. What prevents QML 'containers' from being created which can use something similar to QAction? Why did nothing similar prevent QML MouseArea from using QCursor? > 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. >From here: http://doc-snapshot.qt-project.org/5.0/qaction.html 'In applications many common commands can be invoked via menus, toolbar buttons, and keyboard shortcuts. Since the user expects each command to be performed in the same way, regardless of the user interface used, it is useful to represent each command as an action.' It's not theoretical to use it as a 'property bag', it is what QAction is for. Wherever the QAction is used is automatically 'kept in sync', because the text/icon/status tip/tooltip/etc are in the 'property bag', and the result of invoking it will just invoke a slot. Conceptually, there's nothing 'widgets' in there. It could have been refactored to make it useful for hybrid applications. I don't know why it was not refactored, but I think your argument for justifying not refactoring it and making it useful for hybrid applications is very weak. Thanks, Steve. > 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 > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Stephen Kelly <[email protected]> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
