Karl Pentzlin schrieb:
> Frank da Cruz wrote:
> > Even in the GUI world, as many have pointed out already, we commonly see
> > single-letter shortcuts in dropdown menus. Suppose a German application
> > has:
> > [Ö]ffnen
> > [O]rdnen
> > and the application is reading characters (not keycodes). The application
> > either waits forever for a combining diaeresis that will not come, or it
> > gets a false positive on the 'O' when in fact 'Ö' was typed.
> This situation can be overcome with ease. Compare it with the distinction of
> a single mouse click with a double click - if the second click does not
> happen within a specific time (e.g. 0.5 seconds), the software can safely
> assume a single click. As the "Ö" input choice makes sense only if the
> keyboard has an Ö key (German keybords have one commonly), the application
> has to wait only the time the system needs for the keyboard decoding - i.e.
> on modern systems less than 10 milliseconds.
OK, but now if we are interacting with the same menu over a telecommunications
link of some kind, the possibility for timeout -- and therefore a deadlock --
increases without bound, e.g. when the base character and the combining
diaeresis go out in separate IP packets.
> [BTW, on Microsoft Windows
> systems the software has to wait to the "key released" message anyway - thus
> there would be an unambiguous message sequence "key-pressed - key-O -
> key-diaresis/umlaut - key-released" without the need for any timeout (as
> long as the precomposed letter is not used anyway)].
Yes, but (as noted above) the software reads characters, not keycodes (let
alone make/break sequences). In any case, low-level keyboard access is not
an option across a telecommunications link.
> If the user hits the O
> key instead, he wants to "[O]rdnen" - there is no need to wait seconds
> whether he types in a combining diaresis/umlaut later somehow. If he uses a
> keyboard with a "diaresis/umlaut dead key", he will type it *before* the O
> anyway (to indicate to the Unicode-conformant software that it has to store
> the dead key and to append the code later to the result of the following
> keyboard input).
Again, assume that Unicode characters are being delivered to the application,
not keystroke codes. It should be immaterial to the application how the
O-umlaut was entered: dedicated key on German keyboard, dead-key sequence,
or some other kind of input method.
Anyway, we are going around in circles -- all of these points have been made
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT