2002-02-26  Tor Lillqvist  <tml@iki.fi>

	* 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.h
	* 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.