The future of KAction

[Hamish Rodda]

On Saturday 12 November 2005 22:55, Kevin Krammer wrote:
> On Saturday 12 November 2005 08:04, Hamish Rodda wrote:
> > > > * 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.
>
> That means the receiver class gets an artifical dependency on QApplication.
> By the same reasoning there would be no need for QMouseEvent to transport
> any data other than the activating button, position can be retrieved from
> QCursor and buttons state from QApplication.

Ok, it would probably make sense to provide a triggered(bool checked, 
Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers) signal from 
KAction.  It will be easy to do, just need to listen for triggered(bool) and 
tag on the extra info.

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