[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: The future of KAction
From: Hamish Rodda <rodda () kde ! org>
Date: 2005-11-20 2:29:35
Message-ID: 200511201329.39488.rodda () kde ! org
[Download RAW message or body]
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.
[Attachment #3 (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic