The future of KAction

[Hamish Rodda]

Hi David,

Thanks for your response, they are of course important issues which I will 
attempt to address:

On Saturday 12 November 2005 06:06, you wrote:
> On Friday 11 November 2005 07:38, Hamish Rodda wrote:
> > The other big change that I can see is that the plugging and unplugging
> > moves to be each widget's responsibility.
>
> That's the huge change, which I'm not too comfortable with.
> If you want a special action in a toolbar, like say a koffice-color-chooser
> toolbar button with popup, the solution was to inherit from KAction and
> reimplement plug. But if now the responsibility is in the widget, how do we
> do that? Subclassing QToolbar in an application sounds like the really
> wrong way to attack the problem, doesn't it?
>
> (Of course this example has other solutions, like a way to set a popup to a
> standard toolbar button, but there are many other cases of custom
> actions...)

In my mind I was thinking the same as Olivier, but I didn't write it in my 
email.  So, KAction provides a virtual toolBarWidget() function, which 
KToolBar uses to create a custom widget if one is required.

This means that KActions with custom widgets can only be used with KToolBar, 
which I think is reasonable, and can easily be documented as such.

> > * the activated() signal with the activation reason.  I can't see the
> > required hooks anywhere.
>
> Please look in kbookmarkbar and kbookmarkmenu, as well as konq.
> This allows to detect RMB, Shift+LMB, Ctrl+LMB, Shift+LMB on MenuItem (for
> trash) etc. I would very much hate to lose those features after having
> worked on adding them to 3.4 ... (you saw the @since, right? :)

Yes, I am aware of the @since.

I have considered this further: as long as the receiver is in the same thread, 
QApplication::keyboardModifiers() and QApplication::mouseButtons() should 
return the same values as when the action is activated, since no further 
event processing will have been done (correct me if I'm wrong).  I would 
consider it highly unlikely that this feature would need to be used across 
threads, and if so, surely the programmer can do a little more work to save 
the modifiers and buttons flags themselves before transporting the signal 
across threads.

As for the activation reason, the only place I can find that it is actually 
used is:
* KDirOperator, Konqueror and KDesktop.  Here, files are deleted rather than 
being trashed when shift is held and the action is activated via popup menu.

* Quanta (TagAction) uses it to detect emulated actions only.  The reason 
isn't too clear (perhaps the Andras et. al. could fill us in)

* komacro in playground/office connects to the signal but doesn't use the 
information.

* ksystemlog in playground/sysadmin connects to the signal but only uses the 
modifier state, which can be gained as above.

So, barring Quanta, the only real use is for trash vs delete.  This is a 
feature for advanced users to begin with.  Why should the feature only be 
accessible if the action was triggered from the popup menu?  why not 
shift+delete when the item is selected by itself?  And for that matter, why 
not just have two actions, a trash action, and a delete action?  If 
necessary, the action which shouldn't be displayed when the popup is created 
could be unplugged while the popup is shown.

For Quanta's use, if they still need it, we could add a 
activate(ActivationReason) to KAction, and a signal 
triggered(ActivatitonReason) that they could distinguish between emulated and 
user-generated activations; this would be reasonable.

> > 3) KAction subclass issues
> > Some would be kept, others are not required any more given QActionGroup's
> > capabilities.
>
> But what's the point of a subclass if it can't customize the way the action
> looks like, when plugged in? How do we get a KLineEdit, a KComboBox, a
> KToolbarButton etc.?

As Olivier said, this is answered above.

> > 4) Other issues
> > For KShortcut, it would probably be easiest to replace with QKeySequence,
> > or subclass QKeySequence.
>
> No.  KKeySequence uses QKeySequence already, but KShortCut is one level
> above that, it allows *alternative* key sequences for a given action. E.g.
> Ctrl+C and Ctrl+Insert are two alternatives for "Copy".

Ok, here I was too hasty, you are correct.  This I can work around by 
implementing ::keyPressEvent in KMenuBar, KToolBar, KMenu, etc., and 
iterating the actions to look for alternative shortcuts that are matched, if 
the parent class had not already accept()ed the keypress.  It means that 
alternate shortcuts will only work with K* classes, which I again think is 
reasonable.

> Please let's not use a big axe and "use QFoo because it's in Qt". There are
> many things from the current code that we *do* need, so let's only switch
> to QFoo solutions when they provide the same amount of
> features/flexibility/functionality (or if we can provide subclasses that
> do).

I am not saying we should use QAction "because it is in Qt" - it has been in 
QT since at least 2.3 (I don't have the docs from before), it just wasn't as 
essential to the way Qt created GUIs back then.

Here are the reasons I think we should subclass QAction:
* QMenu, QMenuBar, and QToolBar have all become dependent on QAction - it has 
replaced id numbers and indexes.

* KAction will otherwise be more of a barrier to porting of plain Qt 4.x+ 
applications to KDE.  KDE programmers will be able to do things "the Qt way" 
- this is significant because Qt's interfaces have changed because they were 
considered (apparently through much research) to be an improvement.

* Currently KDE functions by using the Qt3 support methods which internally 
create QAction subclasses which store the id numbers.  If we are ever to 
remove KAction's dependancy on qt3 support, we will either have to move that 
compatibility to our own code (perhaps by keeping an id <==> QAction map), or 
switch to using QAction*, whether by subclassing or by using it in place of 
ids in KAction.

* We will lose minimal functionality in switching, as established above

* _Significant_ savings in the amount of code needed to accomplish the same 
tasks, as the code is in Qt.  That also means that Trolltech has the accepted 
the maintenance for that code.  I did start on this change yesterday, and my 
experience to date (at a guess only) has been 70% deletion of code, 20% 
porting of code, and 10% creation of new code.  As an example, all of the 
code just to decorate toolbuttons on hover could just be deleted.

* Olivier suggested the code required for workaround purposes is great - I 
don't think so at this point.

I think for now I'll wait on the responses to this before I do any further 
work on it - don't want to be doing work for nothing...

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/20051112/830ccc55/attachment.sig>