Tetsuya HAYASHI tetha@st.rim.or.jp had sent me some patches to work around some issues with unicode support in the carbon macintosh VM, and I've had some comments about how keyUp works.
I've integrated Tetsuya HAYASHI changes into a 3.7.3b2 VM that is available for testing in
http://homepage.mac.com/johnmci/ Squeak 3.7.3Beta2.app.sit
This VM only contains the mac os-x carbon binary, not the classic binary since that is still being revised.
The other really big change, which took me all day to resolve was reworking keyUp processing.
So given keyboard input I now:
a) note the raw key down, b) note a possible raw repeat key
c) Process the text services unicode event, and put a keyDown on the event queue. d) Then put a keyChar on the event queue. e) Now either a possible raw repeat key may occur or has occurred, thus another text services unicode event, occurs. f) This generates only a keyChar event since I've seen the key repeat and we wait for the keyup, or more key repeats. g) Finally on a raw key up event, we send the keyUp event for the key indicated as coming up.
Now if you invoke Input Services then you either can enter a single character by clicking on a palette, or input a phrase by typing multiple keys and hitting the return key.
a) This action is noted as input from Text Services and generates the keyDown, keyChar, and keyUp. b) Or this action results in a number of unicode characters coming in as a text services unicode event, again each unicode character generates the proper sequence of events. c) When typing a phrase this does generates raw key up/down events, but no text services unicode event until you hit the return key. This test case seems to be handled correctly, we do not generate squeak events untile text services gives us the one or more unicode characters.
Things to test.
a) Ensure I've not broken Euro character support based on different keyboards (french/swiss/german) I've not access to. b) Ensure I've not broken the dead key support. c) Ensure keyboard Pallette Input Services works correctly. d) Ensure Input Services for phrases works correctly, that generate one or more characters. e) Test the other changes listed below. f) Finally does multiple key down/up activity seem correct if you are looking for that key up and expect to see it when one actually releases the key? Remember of course you can have one or more keys down, not sure what limit the hardware allows.
In a day or two I will work on the os-9 VM and see how to fix any issue with keyUp timing, then create a combined VM.
Tetsuya HAYASHI wrote: ----------------------------- 1) About key input We need MacRoman characters; so current version converts unicode chars using CFStringGetCString(). but, this function return NULL, if base characters (such as japanese) are not included in MacRoman encoding map. I add NULL checking, if it is NULL then return Unicode character. This enables to handle Japanese characters from TSM. If you worry that returning a Large character code(UCS2) occurs error in image, I suggest to add some guards just like check gCurrentEncoding == kCFStringEncodingUTF8. (I think this means using with m17n package) this patch is in recordKeyboardEventCarbon() : sqMacUIEvents.c
2) About PBGetVolumeInfoSync In dir_Lookup() function, PBHGetVInfoSync() couldn't handle a volume name in unicode characters. I heard that some people often named their volumes (drives) with familiar words not ascii characters. I copied dir_lookup() function and use PBGetVolumeInfoSync() to get a name in unicode. but I have not yet coded for getting a creation date, a modified date, sorry... this patch is in dir_lookup() : sqMacDirectory.c
3) About FSSpec name field encoding Sad to say, FSSpec could not handle Unicode strings in a name field. I did quick hack, a function converts unicode strings to native encoding (unicode2NativePascalString(), but this should be C macro ?), and add a patch to FSMakeFSSpecCompat() function. this patch is in unicode2NativePascalString() : sqMacFileLogic.c FSMakeFSSpecCompat() : sqMacFileLogic.c
and, I changed encoding parameters. this reason is same as above. HandleOpenAppEvent() : sqMacUIAppleEvents.c HandleOpenDocEvent() : sqMacUIAppleEvents.c getFirstImageNameIfPossible() : sqMacUIAppleEvents.c
4) About normalization for UTF-8 Apple uses decomposed UTF-8 encoding in file system. I referred to Ian's unix-quartz codes. and add some patches to Carbon codes. Important point is there are two directions of normalization, because current m17n package could not handle decomposed UTF-8 strings, instead handle pre-combined strgings. for example, 'vm -> image' then use kCFStringNormalizationFormKC (to be pre-combined). 'image -> vm' then use kCFStringNormalizationFormKD (to be decomposed). but, I suspect POSIX APIs are able to handle pre-combined characters, so there are no need for normalization 'image -> vm' (kCFStringNormalizationFormKD). this patch is in dir_lookup() : sqMacDirectory.c SetVMPath() : sqMacEncoding.c SetImageNameViaCFString() : sqMacEncoding.c makeFSSpec() : sqMacFileLogic.c PathToFile() : sqMacFileLogic.c quicklyMakePath() : sqMacFileLogic.c makeOSXPath() : sqMacFileLogic.c resolveLogName() : sqMacFileLogic.c
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Bert Freudenberg bert@impara.de pointed out that he had an issue with key ups when dealing with multiple keys. Yes he's right I made a novice mistake with a global, now I'm tracking repeats and key ups by individual keycodes which is required when you can have four keys or so in motion.
Please look for a 3.7.3b3 VM in the usual place and of course more testing is required.
On Apr 11, 2004, at 12:26 AM, John M McIntosh wrote:
Tetsuya HAYASHI tetha@st.rim.or.jp had sent me some patches to work around some issues with unicode support in the carbon macintosh VM, and I've had some comments about how keyUp works.
I've integrated Tetsuya HAYASHI changes into a 3.7.3b2 VM that is available for testing in
http://homepage.mac.com/johnmci/ Squeak 3.7.3Beta2.app.sit
This VM only contains the mac os-x carbon binary, not the classic binary since that is still being revised.
The other really big change, which took me all day to resolve was reworking keyUp processing.
So given keyboard input I now:
a) note the raw key down, b) note a possible raw repeat key
c) Process the text services unicode event, and put a keyDown on the event queue. d) Then put a keyChar on the event queue. e) Now either a possible raw repeat key may occur or has occurred, thus another text services unicode event, occurs. f) This generates only a keyChar event since I've seen the key repeat and we wait for the keyup, or more key repeats. g) Finally on a raw key up event, we send the keyUp event for the key indicated as coming up.
Now if you invoke Input Services then you either can enter a single character by clicking on a palette, or input a phrase by typing multiple keys and hitting the return key.
a) This action is noted as input from Text Services and generates the keyDown, keyChar, and keyUp. b) Or this action results in a number of unicode characters coming in as a text services unicode event, again each unicode character generates the proper sequence of events. c) When typing a phrase this does generates raw key up/down events, but no text services unicode event until you hit the return key. This test case seems to be handled correctly, we do not generate squeak events untile text services gives us the one or more unicode characters.
Things to test.
a) Ensure I've not broken Euro character support based on different keyboards (french/swiss/german) I've not access to. b) Ensure I've not broken the dead key support. c) Ensure keyboard Pallette Input Services works correctly. d) Ensure Input Services for phrases works correctly, that generate one or more characters. e) Test the other changes listed below. f) Finally does multiple key down/up activity seem correct if you are looking for that key up and expect to see it when one actually releases the key? Remember of course you can have one or more keys down, not sure what limit the hardware allows.
In a day or two I will work on the os-9 VM and see how to fix any issue with keyUp timing, then create a combined VM.
--
======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Am 14.04.2004 um 07:19 schrieb John M McIntosh:
Bert Freudenberg bert@impara.de pointed out that he had an issue with key ups when dealing with multiple keys. Yes he's right I made a novice mistake with a global, now I'm tracking repeats and key ups by individual keycodes which is required when you can have four keys or so in motion.
Much better now!
However, not all keys generate key/up down events - for example, shift, ctrl, or dead keys. Also, the key value is not constant - pressing A does not always generate a key value of 65, but sometimes 97, 225, 226, depending on which modifiers and dead keys were pressed,
Up/down events should just generate raw key codes, and should not be processed by the more sophisticated translation services.
- Bert -
Bert it's a bit more complicated, first: {Note I'm looking for comment here if we should change how keyboard events work}
Originally the code that was written for Squeak 2.8 tossed back the apple keyboard physical key number for EventKeyUp or EventKeyDown, versus the ascii representation which comes up from the vm for EventKeyChar this 'feature' is a fallout of a note from Andreas aug 8th 2000 to me which stated:
So on the Mac you would have to generate two events upon a MacOS keyDown event, a 'key down' event containing the virtual key code and a 'character' event containing the character code (both with modifiers). On Unix and Windows the two events would be generated as well, just from two OS events rather than a single one.
Lately this was changed in the macintosh os-x carbon VM and the current os-9.x classic VM to return the Unicode character versus the apple keyboard physical key number on keydown and keyup. For keychar we return the macroman value, unless text services entry is feeding us a string of unicode character. In that case we return the unicode since we do not know what the macroman characters are.
As you noticed then on KeyUp you get the unicode text services translated value which *SHOULD* match the keydown information. So when you press option-a I send you the unicode value for the accented character on key down, the macroman value for keychar, and finally the unicode value for the accented character on keyUp when you let go of the 'a' key.
Technically I could send a key down/up which would contain the MacCharCodes based on keyboard type, then keychar which would be the unicode after text services process the keystrokes. However that is different than what is currently being done and I'm not sure of the impact (other can comment).
Now the issue with returning the control keys is that historically those have come up as states on mouse events. This requires you to look at evensensor and see if the shift key is down or up via polling. We'd have to track the state and build keystroke events, a bit of a hassle... Or rewrite eventsensor to broadcast state changes in control key values. That would be preferable.
PS the os-9.x macroman to unicode translation is below so you can see how that would affect keychar processing if we switch from passing up macroman to unicode?
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24, 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46, 47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68, 69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90, 91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109, 110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126, 127,196,197,199,201,209,214,220,225,224,226,228,227,229,231,233,232, 234,235,237,236,238,239,241,243,242,244,246,245,250,249,251,252,8224,
176,162,163,167,8226,182,223,174,169,8482,180,168,8800,198,216,8734,177,
8804,8805,165,181,8706,8721,8719,960,8747,170,186,937,230,248,191,161,17 2,
8730,402,8776,8710,171,187,8230,160,192,195,213,338,339,8211,8212,8220,8 221,
8216,8217,247,9674,255,376,8260,8364,8249,8250,64257,64258,8225,183,8218 ,8222,
8240,194,202,193,203,200,205,206,207,204,211,212,63743,210,218,219,217,3 05,710, 732,175,728,729,730,184,733,731,711};
On Apr 14, 2004, at 5:51 AM, Bert Freudenberg wrote:
Am 14.04.2004 um 07:19 schrieb John M McIntosh:
Bert Freudenberg bert@impara.de pointed out that he had an issue with key ups when dealing with multiple keys. Yes he's right I made a novice mistake with a global, now I'm tracking repeats and key ups by individual keycodes which is required when you can have four keys or so in motion.
Much better now!
However, not all keys generate key/up down events - for example, shift, ctrl, or dead keys. Also, the key value is not constant - pressing A does not always generate a key value of 65, but sometimes 97, 225, 226, depending on which modifiers and dead keys were pressed,
Up/down events should just generate raw key codes, and should not be processed by the more sophisticated translation services.
- Bert -
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org