The future of KAction
rodda at kde.org
Sun Nov 20 02:29:35 GMT 2005
On Saturday 19 November 2005 21:55, Simon Hausmann wrote:
> 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
> QAction *action();
> QWidget *colorTableWidget();
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel