KSelectAction

[Chusslove Illich]

(Picking this message to reply to just because it has some kind of summary 
and including i18n keyword :)

> [: Hans Meine :]
> 1) Hardcoded accels (the ampers&and way) are bad, because they can
> easily lead to clashes and the same holds for every translation.
>
> 2) Theroretically, there is room for improvement - the current manager
> cannot automatically find the best accelerator, which requires some kind
> of intelligence.
>
> 3) Solving 2) is made much more difficult by the need for i18n.

I have nothing to add to this thread in terms of what-to-do-next, but I've 
a need to dump some blue sky thinking. I'm also a non-Latin user 
(Cyrillic).

It seems to me that the problem with accelerators shouldn't be a problem at 
all, with a slight change in thinking. That is, I think that we (ok, 
perhaps not I :) are trying to come up with a technical solution for a 
problem badly posed in the first place.

Before else, consider one use case: I'm typing English text in 
Cyrillic-localized program, or vice versa. This means that I won't be able 
to use accelerators at all, as they are posed now, since my text-input 
layout won't match command-input layout.

Then, it *seems* to me (HIG people could comment here) that there are two 
usual ways people tend to do with accelerators: not use them at all (use 
mouse), or use them frequently. As said in the previous paragraph, I 
cannot rely on accelerators, so I use mouse. Other people in the thread 
have mentioned that it's pain when the accelerators change, since they 
have remembered them and use them without looking.

Two previous paragraphs combined, I put forward the following conjecture: 
accelerators should be treated like symbols, completely within decided 
upon command-script (English Latin), and unchanging across languages.

Pressing Alt+key should *not* get symbol from whatever input layout 
currently active, but from preset and fixed command-layout, one that has 
full command-script on it (for the non-Latin world, that could be en_US).

Visual cue about accelerators then should not be in the GUI string itself, 
but could appear next to it when Alt is pressed and held. Eg when Alt is 
free:

[ ] Case sensitive

and when pressed:

[ ] Case sensitive _C_

This solution would bring the following:

1) No mixing with input layouts. This would encourage people to remember 
accelerators and reliably count on them being where they are supposed to.

2) No translation hassles. This would encourage programmers to design 
accelerators for best usability, eg. frequent ones fixed manually and 
across programs, and infrequent at accelerator manager's control.

3) Non-disturbing/highly-visual accelerator cues. If the user uses mouse 
only, the strings are clean; once he presses Alt, he gets HIG-decided 
visible accelerator (upper case, italic, different color?), at expected 
location (end of string).

In case somebody is wondering, non-Latin keyboards almost always mount 
en_US layout on key caps in some way (different color on the cap, on side 
of the cap, etc.)

-- 
Chusslove Illich (Часлав Илић)
-------------- 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/20060731/4e767fb2/attachment.sig>