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. Michael _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
