The future of KAction

David Faure faure at kde.org
Fri Nov 11 19:06:41 GMT 2005


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

> * 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? :)

> 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.?

> 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".

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

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list