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