The future of KAction

[Simon Hausmann]

On Tuesday 15 November 2005 14:52, Hamish Rodda wrote:
[...]
> > How does that look?
>
> I like the proposed GUI building API, it seems cleaner and more
> self-documenting.  It would also allow us to remove the "const char* name"
> parameter from KAction's constructors, while still allowing for a
> non-verbose API.
>
> However, are you saying that KAction should not provide custom widgets, and
> if they are needed that each application should code the custom widget?
> Although it is idealistically more pure, I would suggest that it does not
> promote code reuse as much as if KAction could provide the custom widget.
> Eg:
>
> class KColorAction : public KAction
> {
> <blah>
>
> 	const QColor& currentColor() const;
> 	void setCurrentColor(const QColor& newColor);
>
> protected:
> 	/// Overridden to provide the color selecting widget
> 	virtual QWidget* toolbarWidget();
>
> public signals:
> 	void triggered(const QColor& newColor);
> };
>
> Even though the original signals (triggered(bool)) are less useful, they
> can provide their own signals which allows for encapsulation in a similar
> way to a regular action.

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 :)

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);
};

Simon