KSelectAction

[Ingo Klöcker]

On Sunday 30 July 2006 10:58, Stephan Kulow wrote:
> Am Freitag, 28. Juli 2006 15:00 schrieb Hans Meine:
> > Maybe that's overly complex (it
> > would have to be translated, too...) and the existing manager
> > already contains some basic AI logic (I did not check).
>
> The manager already has weightening - your message has some suprises
> to me though. You combined "Check for New Mail" with "cnema" - why do
> you think that &e is better than &f as in &for?

Don't know. But "for" is a pretty generic word. The important words in 
this action are "Check", "New" and "Mail" (which are incidentally all 
capitalized).

One problem with &f and &i is that those characters are so damn narrow 
and thus the line marking the accel will be very short. For example, 
look at Attach->Append S&ignature in KMail's composer. The line below 
the 'i' is really hard to see because it's so short and because it's 
immediately next to the lower part of the 'g'.

Another example would be "Use Fixed Font". IMO the 'x' is the best accel 
for this because the important words here is "Fixed" and since 'x' 
doesn't occur very frequently in other words. So it should be very easy 
to remember.

Also note that "Use Fixed Font" occurs in the View menu of the main 
window and in the View menu of the composer. It would be rather 
confusing if different accels would be used.

I think it's near impossible to get really good results by using 
automatically assigned accels. How would the manager know that "Use" 
and "Font" are much less significant than "Fixed"?

FWIW, I think for (configuration) dialogs managed accels are okay. They 
are not used very often. I guess most people will anyway use the mouse 
to do something in a configuration dialog. But menus are accessed all 
the time with the keyboard. I see the problem with merged menus, but 
then let's restrict managed accels to those problematic merged menus.

And wrt to translation one should probably make more use of the "i18n 
with context" function. If we could standardize on usage of the 
context, e.g. "Menu View -> Use Fixed Font", and then make the 
translation tools so smart that they group all "Menu View" items 
together then the translator should be able to find good accels (with 
the help of a manager proposing accels of course). Alternatively, the 
translators could simply omit setting accels and leave it to the 
manager. I don't see why we shouldn't hardcode good accels for the 
English "translation" just because of other translations.

Regards,
Ingo
-------------- 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/20060730/0923d784/attachment.sig>