KSelectAction

[Hamish Rodda]

On Thursday 27 July 2006 17:47, Thomas Zander wrote:
> On Thursday 27 July 2006 05:53, Hamish Rodda wrote:
> > > 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.
>
> Well, if you mean that any change made to the text is to be made to the
> action, then I think you are missing out on an easier solution. One that
> is just as correct from a design viewpoint.
>
> To have that close a coupling there is just not working; that leaves no
> space for added accels without changing that should never be changed; the
> action.
>
> I propose to add a KMenuItem class which has a action for a constructor
> and has a void setAccellerator(QChar char) and / or setAccellerator(int
> charPosition);
> This class is the one that is added to the KMenu instead of the direct
> actions.
>
> I've seen this work for many years in other toolkits and I think this is a
> better idea.

It is technically feasible, yes.  It does however mean that unexpected results 
would occur if the programmer tried to compare actions with those in the 
menu, or insert an action after a given other action (which would only have 
its proxy in the menu), and workarounds would be required.

> > > 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;
>
> I get some negative vibes from you about that manager :)

Not just vibes, I have stated my viewpoint against it.  I am in favour of 
providing better design time tools, perhaps with automatic accelerator 
suggestions there, so that accelerators won't change randomly (I still 
remember when KMail's Search: bar would randomly have 'a' or 'r' as the 
accelerator).

> Removing the accelerator manager is just not an option. GUIs are build
> more often without any accells assuming the manager will add them.  And
> thats a good thing.

I won't stand in the way of someone implementing this, but I disagree with 
your assertion.

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/20060728/23f54e42/attachment.sig>