The future of KAction

Simon Hausmann hausmann at
Mon Nov 21 06:19:40 GMT 2005

On Sunday 20 November 2005 03:29, Hamish Rodda wrote:
> 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?

I'd say that should be documented as a limitation then, and the implementation 
could print a warning, much like adding a widget that already has a layout to 
another layout. There's no way to make it work (unlike with menu() 
unfortunately) and apart from this case it's the easiest way to provide it in 
QAction (can't add a virtual method there).

> 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.

I agree that's missing in the QToolBar API.

> > 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.

The thing that strikes me with inheritance from Q/KAction in this case is the 
fact that it does not really behave as an action anymore. The triggered() 
signal neither makes sense or should it be emitted to the developer using the 
color selector.

I see your point that with inheritance it's easy to go from a generic QAction 
to a 'KColorAction' by casting, but I'm not convinced that's a common thing 
to do.

Anyway... details... ;-)


More information about the kde-core-devel mailing list