[Development] Move QAction from QtWidgets to QtGui

[André Somers]

Op 3-7-2012 18:45, simon.hausmann at nokia.com 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
>