[squeak-dev] Accented character input

>   We finally get around to attack the accented character input problem
> (mainly thanks to Hiroshima-san).  At least on OLPC, the "dead-key"
> style accented character input seems to work fine with the new VM.


  Oh, I forgot to mention that you have to use the latest OLPC etoys
image.  To try it, please get:

        http://tinlizzie.org/olpc/etoys-dev-3.0.zip
and
        http://tinlizzie.org/olpc/EtoysV3.sources

and SVN the source code for the VM from:

        http://squeakvm.org/svn/squeak/branches/olpc/


-- Yoshiki

On Mar 20, 2008, at 6:26 , Yoshiki Ohshima wrote:
>  Hello,
>
>  We finally get around to attack the accented character input problem
> (mainly thanks to Hiroshima-san).  At least on OLPC, the "dead-key"
> style accented character input seems to work fine with the new VM.
>
>  However, when I switched my Gnome setting on Fedora laptop (it has
> keyboard in Japanese layout) to use Spanish layout keyboard, and
> switch the language to Spanish, my keyboard went into a strange state
> and I needed to do some random key combinations to get to a stuation
> where the new VM works fine.
>
>  I do have a feeling that on a properly configured spanish Linux
> install with the real spanish keyboard and everything, this you should
> be able to type accented characters (and ' and `, etc.) in the way you
> like.  Please test it and let us know how it goes.  Right now, you
> have to compile the VM by yourself... as soon as we are more
> confident, Bert can make a RPM, and Ian will add this to the
> mainstream Squeak VM.  (Or, making RPM is almost free... Probably by
> the time I wake up tomorrow, Bert may have a precompiled VM^^;)



Hehe. Not until next week I guess. We need to switch the image rpm to
3.0, too, because of the new DBus plugin. For that we need to rebuild
the guides etc. And uploading that takes ages when I'm out of office
(I'm almost off to a long Easter weekend).


- Bert -

  José,

  Thank you for checking!


> A stupid checking:
> adding the class UTF32InputInterpreter to the image (if it's not an olpc image that already has this class), and
> assuring that Latin1Environment>>inputInterpreterClass returns UTF32InputInterpreter , everything works with current
> mainstream squeak-vm. None of the last changes on the olpc image are
> needed (at least for spanish language).


  Everything, including accented character input with "dead_keys"?
Hmm.

> It's a very simple fix, I can not understand why this method is nowadays still returning  MacRomanInputInterpreter.
> Any reason to justify it?
> Even in the olpc image there is a long conditional to assure MacRomanInputInterpreter is returned when sugar is not
> present: am I loosing something or there is no justification for
> this behaviour?


  Wtih update 1925 to the etoys 3.0 stream, I ditched the "long"
conditional and now it simply returns UTF32InputInterpreter.

-- Yoshiki

Actually, we should take care of the case when somebody trys to run
the new image on an old VM (UTF32InputInterpreter should look at the
third entry in the event array when sixth is zero...)

  José,


>       Everything, including accented character input with "dead_keys"?
>     Hmm.
>
> Yes, but there is one problem: clicking on the alt or arrow keys
> raises a blank square.


  The blank square problem is fixed in the OLPC version and should be
merged to the trunk version.

  But, I'm still puzzled to hear that dead
key works for you on the VM.  My experimental Spanish setting on my
Fedora might be wrong, but here is my reasoning:

  With a dead key ("'" for example), first time you pressed it, it
doesn't give you the character, right?  Then, you can press "e" to get
e with accent, or you can press "'" again to get a single "'".  This
means that there should be a state kept in the VM to remember the
previous character, but before the patch, there was no such thing.

  Maybe there is some input method in front of the VM that processes
the keyboard input first (like Japanese have)?

>     Actually, we should take care of the case when somebody trys to run
>     the new image on an old VM (UTF32InputInterpreter should look at the
>     third entry in the event array when sixth is zero...)
>
> Yes, but the alternative is worst, so I think that's the best solution.


  Sorry but what was "the alternative"?

  José,


> mmm, if you mean in the X libraries called by the vm, I think that's the case. In fact that works that way whenever you
> use x2sqKeyInput instead of  x2sqKeyPlain at vm-display-X11/sqUnixX11.c. I.e.: if , calling the vm, you use -nointl or
> your locale is not UTF-8, you'll use   x2sqKey= x2sqKeyPlain instead of x2sqKey= x2sqKeyInput, then you'll get the
> accent and the vowel separated. Using x2sqKeyInput you will only get one keycode. That's worked always that way, the
> problem was that the keycode was wrongly interpreted by the image because it was using the MacRomanInputInterpreter
> instead of the UTF32InputInterpreter class.


  Wow, Did I wasted several hours to solve a wrong problem?  I am
*still* in mystery though that Etoys on Spanish OLPC has been in UTF-8
and without -nointl and its had not been working.  More to come...