The future of KAction

[Hamish Rodda]

Hi,

I'm writing to propose a dramatic change for KDE4: the inheritance of KAction 
from QAction.

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

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 
QWidget, actionEvent().

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

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

4) Other issues
For KShortcut, it would probably be easiest to replace with QKeySequence, or 
subclass QKeySequence.

I plan to start working on this now, and hopefully produce a patch in the not 
too distant future... comments will be appreciated.

Cheers,
Hamish.
-------------- 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/20051111/158781c0/attachment.sig>