proposed KAction/KActionCollection API changes

Simon Hausmann hausmann at kde.org
Tue Jan 2 21:30:05 GMT 2007


Hi,

as you may have noticed Kevin and I have been doing some mysterious commits to 
branches/work/kaction-cleanup-branch. We would like to propose a change in 
the API that affects a lot of code. Let me first briefly outline the existing 
KDE 2/3 style API:

KAction and its subclasses are created using single constructor calls that 
combine multiple method calls into one:

KAction *a = new KAction(i18n("&Reload"), "reload", CTRL + Key_F5, this, 
SLOT(reload()), actionCollection(), "view_reload");

This sets the action's text, icon and shortcut, connects the triggered 
(activated) slot, makes the action a child of the passed actionCollection and 
registers it as "view_reload" at the same time.

KAction and KActionCollection are tightly coupled. KActionCollection does not 
support putting QAction objects into it, which however can be a useful thing 
as Qt provides action objects sometimes, for example for dockwidgets or the 
undo-redo stack. One may want to provide KActionCollection's features such as 
the saving/loading of configurable shortcuts for these actions, too.

To developers KActionCollection acts as associative container that maps from a 
name to the action itself. Very often actions are extracted from 
KActionCollection with the name that was passed to the KAction constructor.

In KDE 4 KAction inherits from QAction (finally) and as part of the work in 
the recent weeks we've been able to get rid of quite a bit of cruft in 
KAction to bring the two closer together.

Unfortunately KAction's constructors are right now incompatible with QAction. 
KAction is not a drop-in replacement, it is different because one has to pass 
the name to the constructor along with a KActionCollection as parent. QAction 
on the other hand has only three constructors.

We would like to propose the following changes:

1) KAction and its subclasses get the same 3 (compatible) constructors as 
QAction.

2) Actions need to be explicitly added to the actioncollection. The name used 
for extraction from the actioncollection (and with xmlgui) is specified when 
adding the action to the collection, for symmetry. We would like to use 
KActionCollection::addAction(const QString &name, QAction *action) for that.

3) KActionCollection supports QActions and also provides configurable 
shortcuts for them, through the use of dynamic properties.

[ 4) Get rid of the ugly setObjectName() hiding in KAction ]

The result for application code is that it becomes a lot more verbose:

KAction *a = new KAction(i18n("&Reload"), "reload", CTRL + Key_F5, this, 
SLOT(reload()), actionCollection(), "view_reload");

becomes

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

Or alternatively:

KAction *a = actionCollection()->addAction("view_reload");
a->setShortcut(Qt::ControlModifier + Qt::Key_F5);
connect(a, SIGNAL(triggered()), this, SLOT(reload());


What do people think about this?


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/20070102/85540535/attachment.sig>


More information about the kde-core-devel mailing list