<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> Thank you for checking!<br> <br><br> > A stupid checking:<br> > adding the class UTF32InputInterpreter to the image (if it's not an olpc image that already has this class), and<br> > assuring that Latin1Environment>>inputInterpreterClass returns UTF32InputInterpreter , everything works with current<br>
> mainstream squeak-vm. None of the last changes on the olpc image are<br> > needed (at least for spanish language).<br> <br> <br> Everything, including accented character input with "dead_keys"?<br> Hmm.</blockquote>
<div><br><br>Yes, but there is one problem: clicking on the alt or arrow keys raises a blank square. <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;">
> It's a very simple fix, I can not understand why this method is nowadays still returning MacRomanInputInterpreter.<br> > Any reason to justify it?<br> > Even in the olpc image there is a long conditional to assure MacRomanInputInterpreter is returned when sugar is not<br>
> present: am I loosing something or there is no justification for<br> > this behaviour?<br> <br> <br> Wtih update 1925 to the etoys 3.0 stream, I ditched the "long"<br> conditional and now it simply returns UTF32InputInterpreter.<br>
<br> -- Yoshiki<br> <br> 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> </blockquote></div><br>Yes, but the alternative is worst, so I think that's the best solution.<br><br>Regards.<br>José L.<br>