<br><br><div><span class="gmail_quote">2008/3/20, Yoshiki Ohshima <<a href="mailto:yoshiki@vpri.org">yoshiki@vpri.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
José,<br> <br><br> > Everything, including accented character input with "dead_keys"?<br> > Hmm.<br> ><br> > Yes, but there is one problem: clicking on the alt or arrow keys<br> > raises a blank square.<br>
<br> <br> The blank square problem is fixed in the OLPC version and should be<br> merged to the trunk version.</blockquote><div><br>Yes, but the olpc version misses the non-english & non-dead-keys characters as ñ,ß, etc. and with the image patch that works.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> But, I'm still puzzled to hear that dead<br> key works for you on the VM. My experimental Spanish setting on my<br>
Fedora might be wrong, but here is my reasoning:<br> <br> With a dead key ("'" for example), first time you pressed it, it<br> doesn't give you the character, right? Then, you can press "e" to get<br>
e with accent, or you can press "'" again to get a single "'". This<br> means that there should be a state kept in the VM to remember the<br> previous character, but before the patch, there was no such thing.<br>
<br> Maybe there is some input method in front of the VM that processes<br> the keyboard input first (like Japanese have)?</blockquote><div><br><br>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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > Actually, we should take care of the case when somebody trys to run<br> > the new image on an old VM (UTF32InputInterpreter should look at the<br>
> third entry in the event array when sixth is zero...)<br> ><br> > Yes, but the alternative is worst, so I think that's the best solution.<br> <br> <br> Sorry but what was "the alternative"?</blockquote>
<div><br><br>Having a new vm that does not work correctly typing non-english texts with old and new images. With this change it will, at least, work typing using new images.<br></div></div><br>Regards.<br>José L.<br>