Re: Win32 keyboard handling changes

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-07-20 at 04:45, Tor Lillqvist wrote:

> #104662: If an IME was used to input a sequence of several Unicode
> characters, inly the first one was made into a GDK event. Now GDK
> events are generated for all the characters.)

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.

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 am now mostly satisfied with how things are working (even though the
> code still needs some refactoring). However, some things that used to
> work don't work any longer. I would like feedback on how important
> these issues are...
> 
> - Previously, the Windowsish way of using Alt+keypad numbers way to
> input arbirtary characters from the *current codepage* worked. Not any
> longer. I don't see this as a big issue, as for GTK text entry, the
> Control+Shift+hex digits way of inputting *Unicode* characters work,
> and IMHO Unicode is preferrable to codepages anyway.

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

In general, I'd think that key input => string should use the
system facilities by default, but I don't know to what extent
that is possible for non-IME languages on Windows.

> - Previously, if you typed a control-letter on a non-Latin keyboard,
> ASCII control character GDK events were still generated. (There is/was
> hacks in the code to look up what ASCII character would be generated
> if the keyboard layout were that of some Latin-based language.) In the
> fixed code, typing Control-alpha on a Greek keyboard, for instance,
> generates GDK events with keyval = Greek_alpha and the CONTROL bit
> on. Is this acceptable? How does it work on X11?

The automatic conversion to control character only applies to
event->string (the code is right in gdkevents-x11.c) so doesn't happen
for anything going through GtkIMContext... event->string is legacy
compat cruft. For event->string it is based on the keyval, so 
it only works for Latin characters.

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.

> - The Windows keyboards have some dead keys that the tables in
> GtkIMContextSimple don't recognize, like the Greek dialytika and tonos
> (U+0385). Should these be added to gtkimcontextsimple.c? Not that I
> know how important these are to actual users of such keyboards.)

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.

Regards,
						Owen