Op 3-7-2012 18:45, [email protected] schreef: > 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. Why could it not be used by itself? I would totally use it to represent actions in the business layer of our applications. > > 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. It would be more than 'just' a property bag. It would have a trigger slot, and a triggered() signal. You would be able to enable or disable it. And yes, it would have some properties. And most importantly: it would have a semantic meaning.
In my previous company, there was quite a big discussion on if we could use QAction in our business layer *because* it was in the QtGUI library. It would have made my life much easier if we would have had a QtCoreAction without GUI dependencies that I could easily 'decorate' with an icon and such in the GUI layer (constructing a QAction based on an existing QCoreAction) before I stick it in a menu, on a toolbar or whereever*. Granted: were it to be moved to QtGUI, I'd probably have the same discussion (I think it probably belongs in Core). For QML, some other properties might be relevant, and a QQuickAction might be needed. However, the concept of the action itself stays the same: some kind of method that may or may not be available, may or may not be active, that has a name and may be available for triggering in different ways. As Steve already said: that applies just as well to QML. It is just that things like the way to specify icons for different sizes and states may be different. André *) Yes, there should be more places where you can use QAction. I don't get why I had to write my own QPushButton subclass to support QAction. > > 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
