On 2010-03-29, at 6:54 AM, Henrik Johansen wrote:
Maybe with a bit more clean-up (Character euro is answering the MacRoman code for example, The keyboardinput handling in Squeak does strange things, at least on a Mac... Alt - § (which gives a euro symbol on my keyboard layout) is read as a WideChar with the correct unicode value on Pharo, but as Char 164 in Squeak. Alt- 5 (â) does a similar thing, reads as correct widechar on Pharo, but on Squeak turns into char 129.
No doubt this is because the InputSensor logic in that image "Squeak" you are using pulls the MacRoman value out of the keyboard event array and passes that unchanged to Morphic. To summarize then I think all current VM (last couple of years) provide unicode values on the keychar event. Now the murky underpinnings, and I"ll only talk about the macintosh VM. The macintosh carbon 4.x VM receives the unicode value, macroman value, and keycode value for each input character, this is after text services has mucked with the keystrokes to deal with characters that require multi-keystroke to create. For the case where a text input widget is used to enter data we convert the unicode values to macroman and have no keycode data. In both cases we use CFStringGetCString() with kCFStringEncodingMacRoman to get the MacRoman value. In the Smalltalk Image the code must then take the combination of key down, key char, key up events (there are three events), and decide what to do. Depending on the frame work that might take data from key up, or key char and work with the macroman value, the unicode value, or even do take just the keycode and lookup the macroman & unicode in the image! In general all VMs attempt to supply the unicode and macroman values, the key code are a platform specific values. In the Cocoa based V5 VM the unicode and keycode is supplied by the event data, however some keyboard usage, oh say the HOME key result in a message send, versus keystroke so we have to create a synthetic keyboard event and build the unicode & keycode data to match the Carbon based VM's behaviour. The MacRoman data comes from NSMacOSRomanStringEncoding via getBytes: from the unicode char. For the iPhone we don't offer keyboard input (*yet*) The more attentive of you folks might wonder about keyboard input and the iPhone/iPad and Scratch.app. Er yes obviously we feed keyboard input to the Squeak VM. For that we have the unicode, and then calculate the rest, the MacRoman data comes from NSMacOSRomanStringEncoding, and we build the KeyCode data using a unicode to keycode table we built from KCHR carbon data. -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================