On Apr 16, 2013, at 3:43 AM, Simon Lipp wrote: >> That's how it's supposed to work. > > But it doesn’t work that way under Windows. Shouldn’t Wine try to stick > to Windows behavior as close as possible ? > >> Wine should never generate WM_DEADCHAR message, it relies in the >> driver to handle dead keys and generate final events. > > I’m sorry but I fail to see any incompatibility between the two > alternatives. Wine can generate WM_DEADCHAR messages AND let X/input > method handle the real processing (and the generation of the final > event) ; this patch never skip the XFilterEvent call, so it’s still up > to your favorite IM to generate the final char from the keystrokes > sequence.
For what it's worth, that agrees with my understanding, too. The Mac driver supports dead keys in the manner that Simon suggests. It generates WM_KEYDOWN for dead keys and returns -1 from ToUnicodeEx() for them, which causes TranslateMessage() to post WM_DEADCHAR. When a subsequent key completes the sequence, ToUnicodeEx() returns the completed character(s) as indicated by the Mac keyboard layout. It all seems to work fine. (It also doesn't interfere with some local, in-progress work to support input methods.) Nothing about posting WM_DEADCHAR takes control over the ultimate translation of keys into characters away from the driver or the windowing/input system with which it interfaces. -Ken
