[Development] Move QAction from QtWidgets to QtGui

[Stephen Kelly]

On Tuesday, July 03, 2012 16:45:06 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.
 
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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-- 
Stephen Kelly <stephen.kelly at kdab.com> | 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120704/3e1bfc77/attachment.sig>