proposed KAction/KActionCollection API changes

[Simon Hausmann]

On Tuesday 02 January 2007 23:32, Thomas Zander wrote:
> On Tuesday 02 January 2007 22:30, Simon Hausmann wrote:
> > KAction *a = new KAction(KIcon("reload"), i18n("&Reload"), this);
> > a->setShortcut(Qt::ControlModifier + Qt::Key_F5);
> > connect(a, SIGNAL(triggered()), this, SLOT(reload());
> > actionCollection()->addAction("view_reload", a);
>
> That last line looks a bit odd to me. Too many repeating of the word
> 'action'. I was thinking of some alternatives;
> KActionCollection:
>   add(..)   // makes more sense to me; shorter but still to the point.
>   insert(...) // makes it look more like a QHash api.

Yes, that is a fair point. But on the other hand for the generic tool classes 
a suffix doesn't help. In all the specific cases Qt at least tends to add a 
suffix. Just compare the amount of actual hits in assistant for 'add' 
and 'insert' to addAction, addItem, insertItem, addWidget, etc.

> Hmm; does C++ allow you to have
>   QAction *addAction(const QString&, QAction *);
> on the same class as
>   KAction *addAction(const QString&, KAction *);
> and
>  KAction *addAction(const QString&);
> ?

I think so, yes. But I actually wanted to remove the return type again of 
those overloads that take an existing action pointer. I can't think anymore 
of a reason to use the return value :)

Simon
-------------- 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/20070103/cee674d9/attachment.sig>