[Development] Move QAction from QtWidgets to QtGui

[lars.knoll at nokia.com]

Short note while on vacations... ;-)

It was a conscious choice by me not to even try to split up QAction.
QAction is very much bound to widgets and I am not convinced at all it's
what we would need in QML.

I think we would be better served in rethinking what is required for Qt
Quick and QML components and then try to figure out whether the class
should best live in QtGui, in QtQml or QtQuick.

Cheers,
Lars

On 7/3/12 6:45 PM, "ext simon.hausmann at nokia.com"
<simon.hausmann at nokia.com> 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.
>
>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.
>
>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
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development