The future of KAction

[Hamish Rodda]

On Saturday 12 November 2005 08:44, Olivier Goffart wrote:
<snip>

> proposed solution:
>
> class KAction : public QAction {
> //...
> /**
>  * @return a widget that will be plugged in the toolbar
>  * @param parent the parent of the returned widget
>  * if null is returned, QToolbar will be responsible of creating the widget
>  * default implementation return null
>  */
> virtual QWidget *toolBarWidget(QWidget *parent);
> };
>
> KToolBar::actionEvent(QActionEvent *event)
> {//...
>    QWidget *w = kaction->toolBarWidget(this);
>    if(w)
>      layout()->insertWidget(position, w);
>    else
>     QToolBar::actionEvent(event);
> }
>
>
> Of course this require to use KToolBar, but i think we can consider that a
> KDE application will use KToolBar

Yes, this was my plan.  I agree that it is reasonable to make KToolBar 
required for custom actions.

> > > 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".
>
> the solution could be is the same as #2  re-implement everything to get it
> work with KShortcut

We don't have to re-implement everything, just ::keyPressEvent() for the 
classes that use the KActions.

> But if we have to re-implement everything, what are the benefits of QAction
>
>
>
> So even if it is possible to work around everything,   what are the benefit
> of QAction ?
>   - there is some function in QWidget to handle action
>         -> but it is easy do without it
>   - most of the code is already coded by TrollTech
>        -> not a gain if we have to code 10x more to work around above
> problems

See the end of my response to dfaure in regards to this.

> QAction is not even designed to be subclassed  (it has no virtual method)
This is true. QAction seems to work more with sending ActionChanged events to 
its widgets, and emitting changed() signals.

If there is consensus to go ahead with this change, I would hope that 
Trolltech may expose a bit more api for us (such as their sendDataChanged() 
function that allows the action to tell all widgets it is plugged into that 
it has changed via those ActionChanged events), perhaps as a protected 
function that calls sendDataChanged().

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/c92c1875/attachment.sig>