The future of KAction
rodda at kde.org
Fri Nov 11 06:38:57 GMT 2005
I'm writing to propose a dramatic change for KDE4: the inheritance of KAction
Disclaimer: all of the following is based on a few hours of code reading...
I'm not entirely familiar with it all, so some of the following may be
Executive summary: making KAction a subclass of QAction would bring KDE much
more into line with the Qt way of creating user interfaces, and make KDE
cleaner and (for the most part) remove code duplication and make porting of
kde widgets much easier. However, a small amount of functionality would be
lost, and some effort would be required to port KDE (compatibility methods
would mean most of the effort could be done over a period of time).
Some background: I'm working on porting KMainWindow to QMainWindow. This
means first porting KToolBar and the other dockable widgets. QToolBar is
very different in Qt4 due to the changes to QAction.
QAction in Qt4 seems to have become a true 1st class citizen - all QWidgets
now have a list of associated actions, and QToolBar, QMenu etc. all use this
list directly to show the graphical items (widgets, entries in the menu,
etc). This has replaced all usage of integers as "id"s. There is also a new
QEvent (QActionEvent), and the corresponding virtual protected function in
1) KAction issues:
I've reviewed the KAction api, and can only see a few KAction features that
aren't already in QAction:
* isShortcutConfigurable / setShortcutConfigurable - whether the shortcut can
be configured by the user
* group: a QString property that doesn't seem to be used inside KAction
(perhaps it is used outside?)
* shortcutDefault - the default shortcut for the action
These can be provided by the new KAction quite easily (except I can't see a
need to keep group(), so I'd probably remove it).
As well as this, QAction has additional functionality, such as the changed(),
hovered(), and toggled() signals (activated() is replaced by triggered()).
The other big change that I can see is that the plugging and unplugging moves
to be each widget's responsibility. When kiosk is active, we would probably
want to install an QApplication event filter to detect action add events, and
remove those actions which are disallowed.
Some features will be difficult if not impossible to keep:
* the activated() signal with the activation reason. I can't see the required
* unplugAll() and isPlugged(). QAction currently does not expose which
widgets the action is plugged into. The only way around this that I can see
would be using a QApplication event filter which watches for add and remove
action events, and tracks them in KAction. Deleting the QAction
automatically removes it from all of the widgets it is plugged into, so the
same effect could be achieved by deleting the action, and recreating it if
needed. Alternatively, the trolls may be persuaded to expose this list if we
ask very nicely (I think it's reasonable enough).
2) KActionCollection issues
At first glance, it seems that QActionGroup provides similar functionality;
however, it's not quite the same, as QActionGroup provides exclusivity of
checked actions, etc - so subclassing QActionGroup doesn't sound to me like
the best idea.
I think it would be best to keep KActionCollection as the QObject parent of
all KActions, as currently.
3) KAction subclass issues
Some would be kept, others are not required any more given QActionGroup's
4) Other issues
For KShortcut, it would probably be easiest to replace with QKeySequence, or
I plan to start working on this now, and hopefully produce a patch in the not
too distant future... comments will be appreciated.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel