>
>
>
> Right, I participated in that thread, but it was left without solution.
> Danil Osipchuk did a great work digging in the vm sources, and it seemed
> that vm was about to be ready to handle dead keys but not finished.
> The last email of the thread was this:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-January/124248.html
>
> So it seems the vm returns two different codes when pressing accents, what
> does not make sense and is not understood by the image.


Here is a short summary. Recent VMs (mac, unix and windows) all have two
fields in the event buffer where they store the keycode - 3th ("old") and
6th - ("new"-unicode). Behaviour though is not consistent - I think linux VM
has bugs with the 6th field for navigation keys - left,right,down,up arrows
and home/end. They seem to be just plainly wrong. Also when a character
outside of ascii region is pressed - 3rd field contains 0. So you need to
use both fields in InputInterpeter ( here is the linux version of
InputInterpeter for Russian):

keyCode: sensor firstEvt: evtBuf

    | keyCode |
    keyCode := evtBuf third.
    "trust the old field if it is control code - a workaround for
inconsistency in unix VM, where evt sixth is wrong for movement arrows, home
and end "
    (keyCode > 0 and: [keyCode < 16r21]) ifTrue: [^keyCode].

    "otherwise rely on the ucs field"
    ^evtBuf sixth.

Now for windows, it gives you always correct keycodes in the 6th field for
ascii region, unicode and movement keystrokes (at least for Russian). When
symbol is outside of the ascii range - 3th fied contains something unrelated
with the ascii code < 128 - old implementation for Win1251 locale has been
broken therefore too. But we don't care if we have can use 6th field.
Unfortunetely mouse wheel movement stores zero there - and again you have to
look at the 3rd field.

So, here is input interpreter for Russian on windows:

keyCode: sensor firstEvt: evtBuf

    " when mouse wheel is rolling the sixth field is not filled  - return
the third field instead"
    evtBuf sixth = 0 ifTrue: [^evtBuf third].
    "otherwise use the ucs field strictly"
    ^evtBuf sixth.

The logic of analyzing two fields is incompatible between windows and linux
- hence to input interpreters.

Now about accents. If my guess is right and one can distinguish between
accent modifiers and chars which are being modified - one can build up a
custom InputInterpeter for, lets say Spanish, and I may try to do this. Two
questions though -
 1) is it supposed by design that deadkeys are handled on the smalltalk
side?
 2) is the information about dead keys available *somewhere* in the event
buffer ( because last time when I checked if I pressed deadkey modifier  the
6th field was zeroed on linux, and I forgot to check the 3rd). I also have
not tried accented characters on windows yet.

cheers,

  Danil




No more progress since then.
>
> Regards.
> José L.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080207/769665b1/attachment.htm