KSelectAction

[Randy Kramer]

On Monday 31 July 2006 09:32 am, Chusslove Illich wrote:
> (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.

I like this idea quite a bit, but I may be biased because I'm a native English 
speaker.  Also, I don't have many (if any) occasions to type non-English 
text.

However, if I were not a native English speaker (and presuming that my 
computer was localized for whatever language I did speak/write), then I'd 
probably want my accelerators to have "mnemonic meaning" in that (my native) 
language.

Further, if I then had to type in some other language (not my native 
language), I'd very likely want to keep the accelerators that I know / love 
from my native language / thinking.

So, I think you can extrapolate what I think is the general solution.  The 
questions include how complicated that would be to implement, and how many 
others feel similarly.

Randy Kramer

> 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.)