The future of KAction
rodda at kde.org
Sat Nov 12 07:04:11 GMT 2005
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
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
As for the activation reason, the only place I can find that it is actually
* 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
* 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
> 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
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel