Re: Win32 keyboard handling changes

[Tor Lillqvist <tml iki fi>]

Owen Taylor writes:
 > Hmm, really, my expectation is that IME is not going to work
 > fully correctly unless you hook in at the correct level
 > of GTK+ - that is, at the level of GtkIMContext.

Hmm. As it is now, GTK doesn't know anything about Windows IMEs. GDK
only handles a single related message, WM_IME_COMPOSITION, which
produces the complete string of Unicode characters that the user has
composed using the IME. From this is then generated GDK key press and
release events for said Unicode characters. It seems to work rather
well, in GTK text entry at least.

I do see one problem, though: While the user is interacting with the
IME, GDK also gets the WM_KEYDOWN and WM_KEYUP messages from his
typing, although those actually are intended for the IME (and do get
handled by it, too. Weird.)

The WM_KEYDOWN messages have a special virtual keycode VK_PROCESSKEY,
and get turned into GDK key press event with GDK_VoidSymbol, so they
hardly can mix up anytrhing? The WM_KEYUPs do contain the actual
virtual keycode, so GTK and the application does get spurious
real-looking key release events. Apparently this doesn't mix up things
either, though?

For instance, when I switch into a Chinese IME (don't know what to
call it, it's the one that has "5.0" in the name in the language
switching menu) and type "ha6" top select one of the candidates that
produces two Chinese characters, GDK for me now generates the events:

GDK_KEY_PRESS 0x00020256 0xe5 group:0 VoidSymbol 0:""
GDK_KEY_RELEASE 0x00020256 0x48 group:0 h 1:"h"
GDK_KEY_PRESS 0x00020256 0xe5 group:0 VoidSymbol 0:""
GDK_KEY_RELEASE 0x00020256 0x41 group:0 a 1:"a"
GDK_KEY_PRESS 0x00020256 0xe5 group:0 VoidSymbol 0:""

GDK_KEY_PRESS 0x00020256 0x00 group:0 U+611F 0:""
GDK_KEY_RELEASE 0x00020256 0x00 group:0 U+611F 0:""
GDK_KEY_PRESS 0x00020256 0x00 group:0 U+52A8 0:""
GDK_KEY_RELEASE 0x00020256 0x00 group:0 U+52A8 0:""

GDK_KEY_RELEASE 0x00020256 0x36 group:0 6 1:"6"

(I don't know Chinese, so if those Chinese characters happen to mean
something rude, I apologise ;-)

Luckily GTK ignores those VoidSymbols and spurious releases of ASCII
chars, so the end effect is correct... Maybe this is more by accident
than by design?

Presumably I could check whether IME interaction is in progress, and
in that case don't generate those extra GDK key press and release
events.

 > I spent some time looking at the Windows IME interfaces when
 > I designed GtkIMContext, and convinced myself at that 
 > time that it would work; I don't remember many details at
 > this point.

I haven't really looked at the IME interfaces or GtkIMContext much at
all, so if it really is necessary to hook IME at that level, it will
take some time before I can understand what to do... (Other
volunteers?)

 > My opinion here is that "GTK+ should be as consistent with the system
 > input methods as possible, and no more". 

OK. I'll see what I can do to get the Alt+keypad numbers functionality
back.

 > Key bindings for GTK+ widgets are handled through an entirely
 > separate code path, and if GdkKeymap is implemented correctly,
 > should be fuzzy for the keyboard group, so whatever key shares
 > the a will work for "Control-a == select all", even in Greek
 > mode.

Yes, but with a Greek keyboard, there is no "a" keysym in the keymap
at all. (No, I don't know Greek either.)

 > Note that GtkIMContextSimple uses GDK_dead_acute for a dead tonos
 > and GDK_dead_diaeresis for a dead dialytika, so I think you should
 > simply map the keyvals correspondingly. There is no character that it
 > would make sense to *either* have a dead acute or a dead tonos on, as
 > far as I know.

 > And in fact, Unicode uses U+0301 and U+0308 (COMBINING ACUTE ACCENT
 > and COMBINING DIARESIS) for tonos and dialyika.

Yes, but the Greek keyboard also has a key that produces *both accents
combined* (U+0385). See
http://microsoft.com/globaldev/reference/keyboards.aspx . (Actually it
has two, you get it either through Shift-W or AltGr-; (assuimg the
physical keyboard is US-International).) Currently this gets
translated into the keysym GDK_accentdieresis, which is not treated as
a dead key by GtkIMContextSimple.

--tml