The future of KAction

Hamish Rodda rodda at kde.org
Sun Nov 20 02:29:35 GMT 2005


On Saturday 19 November 2005 21:55, Simon Hausmann wrote:
<snip>
> Maybe you're right, may it's not that bad to provide the flexibility to
> tweak the action to something that does not behave as an action anymore
> (behavior defined by the triggered() signal) but at least provides the same
> interface for creation (QWidget::addAction).
>
> We could have QAction::setWidget()/widget(), then there would be no need to
> derive. I'll have to think a bit more about that :)

The problem here is what happens in the unlikely event that the action is 
plugged into two toolbars?

However I think it is important that there is a way to get the widgets 
implementing the action.  It should be the job of QToolBar to provide this 
information I think - const QList<QWidget*> widgetsForAction(QAction*) const.  
That way the QAction independence is preserved, and one can use the advanced 
features of QToolButton without having to supply the QToolButton as a widget.

> In any case I agree that it makes sense to have a class that encapsulates
> the color selection, and that could be implemented both ways, either
> through inheritance or aggregation:
>
> class KColorSelector : public QObject
> {
> public:
>     ...
>     QAction *action();
>     QWidget *colorTableWidget();
>     ...
> signals:
>     void colorSelected(const QColor &color);
> };

To me, it's better to use inheritance because a programmer looking at the 
actions() can get to the advanced functionality with a cast, and only one 
QObject creation is required.  But this other method would work too.

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051120/46761594/attachment.sig>


More information about the kde-core-devel mailing list