Tetsuya HAYASHI <tetha at 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 at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===