The future of KAction

[Olivier Goffart]

Le Vendredi 11 Novembre 2005 20:06, David Faure a écrit :
> 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...)

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

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

I can't find a nice solution.
one can add a  KAction::reason()  and re-implement  KAction::event  
KMenu::event  KToolbar::event  to set the reason.  wow, that's complex

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

That's solved in #1

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

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

QAction is not even designed to be subclassed  (it has no virtual method)

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