Commit 93fa867e authored by Committed by Tor LillqvistBrowse files
Implement the functions that until now just were non-functional stubs. For
2002-02-26 Tor Lillqvist <email@example.com> * gdk/win32/gdkkeys-win32.c: Implement the functions that until now just were non-functional stubs. For "hardware keycodes", we use Windows virtual keycodes. Not scancodes, although that at first might seem more low-level and a better match to X11 keycodes. The Windows API is really mixed up and confused with respect to scancodes and virtual keycodes. (Surprised?) Some scancodes are generated by two keys on the keyboard (!), and although the keyboard messages do have a flag to indicate which key the user pressed, other API that take a scan code as input don't let you specify which actual key you mean. (update_keymap): Function to build a X11-like representation of the keyboard. Each key has four keysyms: two levels (nonshifted and shifted) and two groups (normal and with AltGr). (gdk_keymap_get_direction): Use the codepage corresponding to the thread's input locale, not the system codepage. * gdk/win32/gdkglobals-win32.c * gdk/win32/gdkmain-win32.c * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkwindow-win32.h * gdk/win32/gdkwindow-win32.c: Remove the input_locale and charset_info fields from GdkWindowImplWin32. Input locale is per-thread in Windows, and as GDK on Windows really only works when the GDI interaction all happens in just one thread anyway, this state can be global. Use globals _gdk_input_locale and _gdk_input_codepage instead. Set these based on the thread's input locale (keyboard layout, or which IME is active). * gdk/win32/gdkevents-win32.c: Set the group and hardware_keycode fields in GDK key events. On input locale change messages, set the global state variables, and inform update_keymap() that it has to rebuild the keymap.
Showing with 438 additions and 67 deletions