Unicode test II

> On Tue, Mar 3, 2009 at 8:11 AM, Michael Rueger <[hidden email]> wrote:
>> after some interesting adventures in Unicode land here's a second
>> version of the unicode test image/app:
>>
>> http://impara.de/~michael/unicode-test.zip
>
> this one works very well for me. I'm able to type "éàôç" in Pharo
> directly and copy-paste "àóøœüœáßðfµéë" from a text editor into Pharo.
> The following two characters are not well displayed in the workspace,
> but that could easily be a missing glyph in the font: $œ and $ð.

>
> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)
>
> Mostly untested:
> - unicode filename handling
>
> Known not to work:
> - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
> That would take another major refactoring of handling shortcuts.
>
> Once I know this version works reasonable well I'll package everything
> up for inclusion in the updates. Right now it is pretty much a mess.

> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)
>
> Mostly untested:
> - unicode filename handling
>
> Known not to work:
> - keyboard shortcuts in lists (e.g. browsers) on non Latin1 keyboards.
> That would take another major refactoring of handling shortcuts.
>
> Once I know this version works reasonable well I'll package everything
> up for inclusion in the updates. Right now it is pretty much a mess.
>
>
> Happy testing
>
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Long ago when I thought I was going to be writing Operating Systems in
> Assembly Language, I had a raw keyboard driver interpreting the key
> codes from various keyboards.
>
> TERRIBLE to debug (though not as bad as debugging a display driver).
>
> Is that what all this is like?
>
> Ugh...
>
> Do you use lookup tables for all the various keyboard types and
> operating systems?
>
> It seems like you almost need a matrix of all the supported systems vs.
> all the possible keyboards, with a table for each one...it could just be
> a file in the image directory and get loaded at startup.
>
> Then, if someone has some weird keyboard, they could just edit the file...
>
> But then, I probably have no idea what I'm talking about!!!

> Rob Rothwell wrote:
>> Long ago when I thought I was going to be writing Operating Systems in
>> Assembly Language, I had a raw keyboard driver interpreting the key
>> codes from various keyboards.
>>
>> TERRIBLE to debug (though not as bad as debugging a display driver).
>>
>> Is that what all this is like?
>>
>> Ugh...
>>
>> Do you use lookup tables for all the various keyboard types and
>> operating systems?
>>
>> It seems like you almost need a matrix of all the supported systems vs.
>> all the possible keyboards, with a table for each one...it could just be
>> a file in the image directory and get loaded at startup.
>>
>> Then, if someone has some weird keyboard, they could just edit the file...
>>
>> But then, I probably have no idea what I'm talking about!!!
>
> Well, at some level that is what the OS is doing. Fortunately the VMs
> can work on a slightly higher level.
> But...
>
> Although all VMs now deliver unicode values in slot 6 of the input
> event, getting composing keyboards and latin1 based shortcut keys to
> work is still tricky. And I still haven't tested all the important
> combinations of OS and keyboard layouts yet.
>
> The Windows VM does a good job delivering composed sequences, you get
> all the intermediate keys (e.g. " and u), but only one keystroke event
> for the composed character.
> The Linux VM however delivers keystrokes for the intermediate keys, so I
> need to figure out, if there is a single key or a composing sequence
> coming up. That's where the ugly hack comes in, peeking for the next
> event etc.
>
> Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so
> far only tested and probably only there working on Windows. It works by
> looking at the scancode of the key, which is only delivered on the key
> down and up events. Then, in dispatch, I need to look at the unicode
> value delivered, but also at the scan code and if a modifier is pressed.
> The problem is that dispatching of key commands is implemented
> differently all over the system and in no place used the event, but
> simply the character. I refactored it for paragraph editor, but not all
> the other places.
>
> In Sophie we got around that by hacking the Tweak widgets to use
> factored out lookup tables, so there was only one place to deal with that.
> - Show quoted text -
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> I can't mail out a bug report, because when doing it, i again get the
> same error.
>
> Can i send an image.zip to you, so you can take a look at it?
>
> 2009/3/4 Michael Rueger <[hidden email]>:
> - Show quoted text -
>> Rob Rothwell wrote:
>>> Long ago when I thought I was going to be writing Operating Systems in
>>> Assembly Language, I had a raw keyboard driver interpreting the key
>>> codes from various keyboards.
>>>
>>> TERRIBLE to debug (though not as bad as debugging a display driver).
>>>
>>> Is that what all this is like?
>>>
>>> Ugh...
>>>
>>> Do you use lookup tables for all the various keyboard types and
>>> operating systems?
>>>
>>> It seems like you almost need a matrix of all the supported systems vs.
>>> all the possible keyboards, with a table for each one...it could just be
>>> a file in the image directory and get loaded at startup.
>>>
>>> Then, if someone has some weird keyboard, they could just edit the file...
>>>
>>> But then, I probably have no idea what I'm talking about!!!
>>
>> Well, at some level that is what the OS is doing. Fortunately the VMs
>> can work on a slightly higher level.
>> But...
>>
>> Although all VMs now deliver unicode values in slot 6 of the input
>> event, getting composing keyboards and latin1 based shortcut keys to
>> work is still tricky. And I still haven't tested all the important
>> combinations of OS and keyboard layouts yet.
>>
>> The Windows VM does a good job delivering composed sequences, you get
>> all the intermediate keys (e.g. " and u), but only one keystroke event
>> for the composed character.
>> The Linux VM however delivers keystrokes for the intermediate keys, so I
>> need to figure out, if there is a single key or a composing sequence
>> coming up. That's where the ugly hack comes in, peeking for the next
>> event etc.
>>
>> Supporting Latin1 based shortcut keys (x c v cut copy paste etc) is so
>> far only tested and probably only there working on Windows. It works by
>> looking at the scancode of the key, which is only delivered on the key
>> down and up events. Then, in dispatch, I need to look at the unicode
>> value delivered, but also at the scan code and if a modifier is pressed.
>> The problem is that dispatching of key commands is implemented
>> differently all over the system and in no place used the event, but
>> simply the character. I refactored it for paragraph editor, but not all
>> the other places.
>>
>> In Sophie we got around that by hacking the Tweak widgets to use
>> factored out lookup tables, so there was only one place to deal with that.
>> - Show quoted text -
>> Michael
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> - Show quoted text -
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Igor Stasenko wrote:
>> 2009/3/4 Igor Stasenko <[hidden email]>:
>>> Michael, i got an in MultiCompositionScanner.
>> i mean error... :)
>>
>>> I can't mail out a bug report, because when doing it, i again get the
>>> same error.
>
> bummer
> Hmm, shouldn't there be a SqueakDebug.log file though?
>
> at least the method in question and a brief description of what you did
> would help :-)

> Hi all,
>
> after some interesting adventures in Unicode land here's a second
> version of the unicode test image/app:
>
> http://impara.de/~michael/unicode-test.zip
>
> Things that I think should work:
> - unicode text input on all platforms including support of composing
> character sequences (.eg. US international keyboards)
> - unicode clipboard handling
> - text editor shortcuts on non Latin1 keyboards (e.g. Russian) (thinking
> about it, only tested on Windows so far)