KSelectAction

[Hamish Rodda]

On Wednesday 26 July 2006 20:22, Thomas Zander wrote:
> On Wednesday 26 July 2006 10:42, Hamish Rodda wrote:
> > Firstly, KAction doesn't change QAction's handling of text()/setText(),
> > so we're really talking about QAction (and the consequences of porting
> > to it).
> >
> > Secondly, if you read the QAction docs you will see that
> > text()/setText() is symmetric... the only trick is that text passed to
> > the constructor will have processing applied (ampersands removed and
> > accelerator applied), whereas text passed to setText() will not.  This
> > means we need to port calls to setText() (don't set ampersands, use the
> > shortcut instead); I'll add it to KDE4PORTING.html.
>
> ahum;
> stupid question time;  Why does the alteration of the text in the menu due
> to the accel manager adding accels have any effect on the text in the
> action?

The menu gets its text from the actions, period.

> I think the design bug is when altering a widget that is controlled by the
> action actually alters the action at the same time.  The design pattern
> we saw everywhere until now was that there was a one way direction. Alter
> the action and all widgets follow, not the other way around.

Right; this is another argument against accelerator managers; they only 'fix' 
accelerators for the widget they're iterating, and that means if the actions 
are plugged in somewhere else, you get unexpected results.

To avoid this, we'd need our subclass of QMenu to rewrite the rendering of 
QMenu (ouch), and have that subclass hold all of the accelerator manager's 
changes.

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