2009/3/4 Igor Stasenko <[email protected]>: > 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. > > Can i send an image.zip to you, so you can take a look at it? > > 2009/3/4 Michael Rueger <[email protected]>: > - 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > - Show quoted text - > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
