gtk/gdk/win32/gdkkeys-win32.c

949 lines
24 KiB
C
Raw Normal View History

/* GDK - The GIMP Drawing Kit
* Copyright (C) 2000 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
2012-02-27 13:01:10 +00:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
/*
* Modified by the GTK+ Team and others 1997-2000. See the AUTHORS
* file for a list of people on the GTK+ Team. See the ChangeLog
* files for a list of changes. These files are distributed with
* GTK+ at ftp://ftp.gtk.org/pub/gtk/.
*/
#include "config.h"
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
#include "gdk.h"
#include "gdkprivate-win32.h"
#include "gdkinternals.h"
#include "gdkkeysyms.h"
#include "gdkkeysprivate.h"
#include "gdkwin32keys.h"
struct _GdkWin32KeymapClass
{
GdkKeymapClass parent_class;
};
struct _GdkWin32Keymap
{
GdkKeymap parent_instance;
};
G_DEFINE_TYPE (GdkWin32Keymap, gdk_win32_keymap, GDK_TYPE_KEYMAP)
static void
gdk_win32_keymap_init (GdkWin32Keymap *keymap)
{
}
guint _gdk_keymap_serial = 0;
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
gboolean _gdk_keyboard_has_altgr = FALSE;
guint _scancode_rshift = 0;
static GdkModifierType gdk_shift_modifiers = GDK_SHIFT_MASK;
static GdkKeymap *default_keymap = NULL;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
static guint *keysym_tab = NULL;
#define KEY_STATE_SIZE 256
#ifdef G_ENABLE_DEBUG
static void
print_keysym_tab (void)
{
gint vk;
g_print ("keymap:%s%s\n",
_gdk_keyboard_has_altgr ? " (uses AltGr)" : "",
(gdk_shift_modifiers & GDK_LOCK_MASK) ? " (has ShiftLock)" : "");
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
{
gint state;
g_print ("%#.02x: ", vk);
for (state = 0; state < 4; state++)
{
gchar *name = gdk_keyval_name (keysym_tab[vk*4 + state]);
if (name == NULL)
name = "(none)";
g_print ("%s ", name);
}
g_print ("\n");
}
}
#endif
static void
handle_special (guint vk,
guint *ksymp,
gint shift)
{
switch (vk)
{
case VK_CANCEL:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Cancel; break;
case VK_BACK:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_BackSpace; break;
case VK_TAB:
if (shift & 0x1)
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_ISO_Left_Tab;
else
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Tab;
break;
case VK_CLEAR:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Clear; break;
case VK_RETURN:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Return; break;
case VK_SHIFT:
case VK_LSHIFT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Shift_L; break;
case VK_CONTROL:
case VK_LCONTROL:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Control_L; break;
case VK_MENU:
case VK_LMENU:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Alt_L; break;
case VK_PAUSE:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Pause; break;
case VK_ESCAPE:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Escape; break;
case VK_PRIOR:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Prior; break;
case VK_NEXT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Next; break;
case VK_END:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_End; break;
case VK_HOME:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Home; break;
case VK_LEFT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Left; break;
case VK_UP:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Up; break;
case VK_RIGHT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Right; break;
case VK_DOWN:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Down; break;
case VK_SELECT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Select; break;
case VK_PRINT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Print; break;
case VK_SNAPSHOT:
*ksymp = GDK_KEY_Print; break;
case VK_EXECUTE:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Execute; break;
case VK_INSERT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Insert; break;
case VK_DELETE:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Delete; break;
case VK_HELP:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Help; break;
case VK_LWIN:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Meta_L; break;
case VK_RWIN:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Meta_R; break;
case VK_APPS:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Menu; break;
case VK_DECIMAL:
*ksymp = GDK_KEY_KP_Decimal; break;
case VK_MULTIPLY:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_Multiply; break;
case VK_ADD:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_Add; break;
case VK_SEPARATOR:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_Separator; break;
case VK_SUBTRACT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_Subtract; break;
case VK_DIVIDE:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_Divide; break;
case VK_NUMPAD0:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_0; break;
case VK_NUMPAD1:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_1; break;
case VK_NUMPAD2:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_2; break;
case VK_NUMPAD3:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_3; break;
case VK_NUMPAD4:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_4; break;
case VK_NUMPAD5:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_5; break;
case VK_NUMPAD6:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_6; break;
case VK_NUMPAD7:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_7; break;
case VK_NUMPAD8:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_8; break;
case VK_NUMPAD9:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_KP_9; break;
case VK_F1:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F1; break;
case VK_F2:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F2; break;
case VK_F3:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F3; break;
case VK_F4:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F4; break;
case VK_F5:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F5; break;
case VK_F6:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F6; break;
case VK_F7:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F7; break;
case VK_F8:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F8; break;
case VK_F9:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F9; break;
case VK_F10:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F10; break;
case VK_F11:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F11; break;
case VK_F12:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F12; break;
case VK_F13:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F13; break;
case VK_F14:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F14; break;
case VK_F15:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F15; break;
case VK_F16:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F16; break;
case VK_F17:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F17; break;
case VK_F18:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F18; break;
case VK_F19:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F19; break;
case VK_F20:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F20; break;
case VK_F21:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F21; break;
case VK_F22:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F22; break;
case VK_F23:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F23; break;
case VK_F24:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_F24; break;
case VK_NUMLOCK:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Num_Lock; break;
case VK_SCROLL:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Scroll_Lock; break;
case VK_RSHIFT:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Shift_R; break;
case VK_RCONTROL:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Control_R; break;
case VK_RMENU:
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_Alt_R; break;
}
}
static void
set_shift_vks (guchar *key_state,
gint shift)
{
switch (shift)
{
case 0:
key_state[VK_SHIFT] = 0;
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
break;
case 1:
key_state[VK_SHIFT] = 0x80;
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
break;
case 2:
key_state[VK_SHIFT] = 0;
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
break;
case 3:
key_state[VK_SHIFT] = 0x80;
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
break;
}
}
static void
reset_after_dead (guchar key_state[KEY_STATE_SIZE])
{
guchar temp_key_state[KEY_STATE_SIZE];
wchar_t wcs[2];
memmove (temp_key_state, key_state, KEY_STATE_SIZE);
temp_key_state[VK_SHIFT] =
temp_key_state[VK_CONTROL] =
temp_key_state[VK_MENU] = 0;
ToUnicodeEx (VK_SPACE, MapVirtualKey (VK_SPACE, 0),
temp_key_state, wcs, G_N_ELEMENTS (wcs),
0, _gdk_input_locale);
}
static void
handle_dead (guint keysym,
guint *ksymp)
{
switch (keysym)
{
case '"': /* 0x022 */
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_dead_diaeresis; break;
case '\'': /* 0x027 */
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_dead_acute; break;
case GDK_KEY_asciicircum: /* 0x05e */
*ksymp = GDK_KEY_dead_circumflex; break;
case GDK_KEY_grave: /* 0x060 */
*ksymp = GDK_KEY_dead_grave; break;
case GDK_KEY_asciitilde: /* 0x07e */
*ksymp = GDK_KEY_dead_tilde; break;
case GDK_KEY_diaeresis: /* 0x0a8 */
*ksymp = GDK_KEY_dead_diaeresis; break;
case GDK_KEY_degree: /* 0x0b0 */
*ksymp = GDK_KEY_dead_abovering; break;
case GDK_KEY_acute: /* 0x0b4 */
*ksymp = GDK_KEY_dead_acute; break;
case GDK_KEY_periodcentered: /* 0x0b7 */
*ksymp = GDK_KEY_dead_abovedot; break;
case GDK_KEY_cedilla: /* 0x0b8 */
*ksymp = GDK_KEY_dead_cedilla; break;
case GDK_KEY_breve: /* 0x1a2 */
*ksymp = GDK_KEY_dead_breve; break;
case GDK_KEY_ogonek: /* 0x1b2 */
*ksymp = GDK_KEY_dead_ogonek; break;
case GDK_KEY_caron: /* 0x1b7 */
*ksymp = GDK_KEY_dead_caron; break;
case GDK_KEY_doubleacute: /* 0x1bd */
*ksymp = GDK_KEY_dead_doubleacute; break;
case GDK_KEY_abovedot: /* 0x1ff */
*ksymp = GDK_KEY_dead_abovedot; break;
case 0x1000384: /* Greek tonos */
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_dead_acute; break;
case GDK_KEY_Greek_accentdieresis: /* 0x7ae */
*ksymp = GDK_KEY_Greek_accentdieresis; break;
default:
/* By default use the keysym as such. This takes care of for
* instance the dead U+09CD (BENGALI VIRAMA) on the ekushey
* Bengali layout.
*/
*ksymp = keysym; break;
}
}
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
static void
update_keymap (void)
{
static guint current_serial = 0;
guchar key_state[KEY_STATE_SIZE];
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
guint scancode;
guint vk;
gboolean capslock_tested = FALSE;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (keysym_tab != NULL && current_serial == _gdk_keymap_serial)
return;
current_serial = _gdk_keymap_serial;
if (keysym_tab == NULL)
keysym_tab = g_new (guint, 4*KEY_STATE_SIZE);
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
memset (key_state, 0, sizeof (key_state));
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
_gdk_keyboard_has_altgr = FALSE;
gdk_shift_modifiers = GDK_SHIFT_MASK;
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
{
if ((scancode = MapVirtualKey (vk, 0)) == 0 &&
vk != VK_DIVIDE)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
keysym_tab[vk*4+0] =
keysym_tab[vk*4+1] =
keysym_tab[vk*4+2] =
2010-09-09 11:35:20 +00:00
keysym_tab[vk*4+3] = GDK_KEY_VoidSymbol;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
else
{
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
gint shift;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (vk == VK_RSHIFT)
_scancode_rshift = scancode;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
key_state[vk] = 0x80;
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
for (shift = 0; shift < 4; shift++)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
{
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
guint *ksymp = keysym_tab + vk*4 + shift;
set_shift_vks (key_state, shift);
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
*ksymp = 0;
/* First, handle those virtual keys that we always want
* as special GDK_* keysyms, even if ToAsciiEx might
* turn some them into a ASCII character (like TAB and
* ESC).
*/
handle_special (vk, ksymp, shift);
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (*ksymp == 0)
{
wchar_t wcs[10];
gint k;
wcs[0] = wcs[1] = 0;
k = ToUnicodeEx (vk, scancode, key_state,
wcs, G_N_ELEMENTS (wcs),
0, _gdk_input_locale);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
#if 0
g_print ("ToUnicodeEx(%#02x, %d: %d): %d, %04x %04x\n",
vk, scancode, shift, k,
wcs[0], wcs[1]);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
#endif
if (k == 1)
*ksymp = gdk_unicode_to_keyval (wcs[0]);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
else if (k == -1)
{
guint keysym = gdk_unicode_to_keyval (wcs[0]);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
/* It is a dead key, and it has been stored in
* the keyboard layout's state by
* ToAsciiEx()/ToUnicodeEx(). Yes, this is an
* incredibly silly API! Make the keyboard
* layout forget it by calling
* ToAsciiEx()/ToUnicodeEx() once more, with the
* virtual key code and scancode for the
* spacebar, without shift or AltGr. Otherwise
* the next call to ToAsciiEx() with a different
* key would try to combine with the dead key.
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
*/
reset_after_dead (key_state);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
/* Use dead keysyms instead of "undead" ones */
handle_dead (keysym, ksymp);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
}
else if (k == 0)
{
/* Seems to be necessary to "reset" the keyboard layout
* in this case, too. Otherwise problems on NT4.
*/
reset_after_dead (key_state);
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
}
else
{
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#if 0
GDK_NOTE (EVENTS,
g_print ("ToUnicodeEx returns %d "
"for vk:%02x, sc:%02x%s%s\n",
k, vk, scancode,
(shift&0x1 ? " shift" : ""),
(shift&0x2 ? " altgr" : "")));
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#endif
gdk/win32/gdkprivate-win32.h New flags _gdk_input_locale_is_ime and 2003-07-25 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkprivate-win32.h * gdk/win32/gdkglobals-win32.c: New flags _gdk_input_locale_is_ime and _gdk_keyboard_has_altgr. * gdk/win32/gdkevents-win32.c: Lots of changes. Most important ones detailled here. Code that has been ifdeffed out for a long time removed. Remove some really old doc comments that were left behind for some public functions, the official ones are in the X11 backend anyway. Change GDK_WINDOW_OBJECT() calls to GdkWindowObject casts. Reformat multi-line boolean expressions to have the operators at ends of lines. As mouse capture with SetCapture() indeed seems to work OK, no need to have the correspoinding macro USE_SETCAPTURE and ifdefs. Ifdef out the gdk-ping-msg stuff. I don't remember why it was needed at some time, and things seem to work fine now without (knock on wood). Ifdef out the search for some Latin locale keyboard layout being loaded. Not used currently, but might be needed after all, if we decide that we want to be able to generate ASCII control character events with a non-Latin keyboard. (assign_object): New helper function, handles the g_object_ref() and unref() calls when assigning GObject pointers. (generate_crossing_events): Also generate the GDK_NOTIFY_INTERIOR enter event when the pointer has moved to an ancestor window. Was left out by mistake. (gdk_window_is_ancestor): Renamed from gdk_window_is_child(). (gdk_pointer_grab, gdk_pointer_ungrab): Implement the confine_to functionality, using ClipCursor(). (find_window_for_mouse_event): Splice part of code into new function find_real_window_for_grabbed_mouse_event(). (fixup_event, append_event, apply_filters): New functions, code refactored out from elsewhere. (synthesize_enter_or_leave_event, synthesize_leave_event, synthesize_enter_event, synthesize_leave_events,synthesize_enter_events): Also take a GdkCrossingMode parameter, in preparation to generating GDK_CROSSING_GRAB and GDK_CROSSING_UNGRAB events. (fixup_event, append_event, fill_key_event_string): New functions, code refactoring. (vk_from_char, build_keypress_event, build_keyrelease_event): Removed as part of dropping WM_CHAR handling. (build_key_event_state,gdk_event_translate): Call GetKeyboardState(), once, for each keyboard message, instead of several calls to GetKeyState() here and there. (gdk_event_translate): Fix bugs #104516, #104662, #115902. While at it, do some major refactoring, and some fixes for potential problems noticed while going through the code. Don't handle WM_CHAR at all. Only handle WM_KEYDOWN and WM_KEYUP. Don't need the state variables related to whether to wait for WM_CHAR or not, and whether the current key is AltGr. Remove lots of complexity. Thus don't need the use_ime_composition flag. Not handling WM_CHAR means dead key handling will have to be taken care of by GTK, but that seems to work fine, so no worry. Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. Be more careful in checking whether AltGr is involved. Only attempt to handle it if the keyboard actually has it. And explicitly check for *left* Control plus *right* Alt being pressed. Still, allow (left) Alt and/or (right) Control with AltGr chars. Handle keys using similar code as in the X11 backend. As we have built a keymap in gdkkeys-win32.c anyway, use it by calling gdk_keymap_translate_keyboard_state() to look up the keysym from the virtual key code and keyboard state. Build the key event string in exactly the same way as the X11 backend. If an IME is being used, don't generate GDK events for keys between receiving WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION, as those keys are for the IME. For WM_IME_COMPOSITION, handle all the Unicode chars returned from the IME, not just the first one. gdk_event_translate() is still quite complex, could split the message handler cases out into separate functions. On mouse events, when the mouse is grabbed, use find_real_window_for_grabbed_mouse_event() in order to be able to generate correct crossing events. No longer take a pre-allocated GdkEvent as parameter. Instead, allocate events as needed and append them to the queue. (This is different from how gdk_event_translate() in the X11 backend works.) This change made the code much clearer, especially in the cases where we have to generate several GDK events for one Windows message. Return FALSE if DefWindowProc() should be called, TRUE if not. If DefWindowProc() should not be called, also return the value to be returned from the window procedure. (Previously, the interaction with gdk_event_translate()'s caller was much more complex, when we had to indicate whether the already-queued event should be left in the queue or removed, and in addition also had to indicate whether to call DefWindowProc() or not, and what value to return from the window procedure if not.) Don't use a separate "private" variable required to be pointing to the GdkWindowObject of the "window" variable at all times. Just use casts, even if looks a bit uglier. Notice destroyed windows as early as possible, and break out of the messsage switch. Use _gdk_pointer_root as current_window when the pointer is outside GDK's top-level windows. On WM_INPUTLANGCHANGE, set _gdk_input_locale_is_ime as appropriate, based on ImmIsIME(). (gdk_event_translate, gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Implement client messages. Use a registered Windows message to pass GDK client messages. Note that the amount of user data is restricted to four bytes, as it is carried in the LPARAM. (The WPARAM is used for the message type "atom".) (real_window_procedure): Adapt for new gdk_event_translate() interface. * gdk/win32/gdkmain-win32.c (_gdk_windowing_init): Set _gdk_input_locale_is_ime initially. * gdk/win32/gdkwindow-win32.c: Use g_object_ref()/unref() instead of g_colormap_ref()/unref(). (gdk_window_new): Made code a bit more like the X11 one, pretend to handle screens (although we just have one for now). * gdk/x11/gdkevents-x11.c (gdk_event_send_client_message_for_display, gdk_screen_broadcast_client_message): Document the user data limitation on Win32. * gdk/win32/gdkevents-win32.c (print_event): More complete enter and leave notify detail output. * gdk/win32/gdkkeys-win32.c (update_keymap): Make dead keys visible to GDK and GTK. Store the corresponding GDK_dead_* keysym for those, so that the GtkIMContextCimple compose tables will work. Deduce if the keyboard layout has the AltGr key, and set the above flag accordingly.
2003-07-26 01:54:59 +00:00
}
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
}
if (*ksymp == 0)
2010-09-09 11:35:20 +00:00
*ksymp = GDK_KEY_VoidSymbol;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
}
key_state[vk] = 0;
/* Check if keyboard has an AltGr key by checking if
* the mapping with Control+Alt is different.
*/
if (!_gdk_keyboard_has_altgr)
2010-09-09 11:35:20 +00:00
if ((keysym_tab[vk*4 + 2] != GDK_KEY_VoidSymbol &&
keysym_tab[vk*4] != keysym_tab[vk*4 + 2]) ||
2010-09-09 11:35:20 +00:00
(keysym_tab[vk*4 + 3] != GDK_KEY_VoidSymbol &&
keysym_tab[vk*4 + 1] != keysym_tab[vk*4 + 3]))
_gdk_keyboard_has_altgr = TRUE;
if (!capslock_tested)
{
/* Can we use this virtual key to determine the CapsLock
* key behaviour: CapsLock or ShiftLock? If it generates
* keysyms for printable characters and has a shifted
* keysym that isn't just the upperacase of the
* unshifted keysym, check the behaviour of VK_CAPITAL.
*/
if (g_unichar_isgraph (gdk_keyval_to_unicode (keysym_tab[vk*4 + 0])) &&
keysym_tab[vk*4 + 1] != keysym_tab[vk*4 + 0] &&
g_unichar_isgraph (gdk_keyval_to_unicode (keysym_tab[vk*4 + 1])) &&
keysym_tab[vk*4 + 1] != gdk_keyval_to_upper (keysym_tab[vk*4 + 0]))
{
guchar chars[2];
capslock_tested = TRUE;
key_state[VK_SHIFT] = 0;
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
key_state[VK_CAPITAL] = 1;
if (ToAsciiEx (vk, scancode, key_state,
(LPWORD) chars, 0, _gdk_input_locale) == 1)
{
2010-09-09 11:35:20 +00:00
if (chars[0] >= GDK_KEY_space &&
chars[0] <= GDK_KEY_asciitilde &&
chars[0] == keysym_tab[vk*4 + 1])
{
/* CapsLock acts as ShiftLock */
gdk_shift_modifiers |= GDK_LOCK_MASK;
}
}
key_state[VK_CAPITAL] = 0;
}
}
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
}
}
GDK_NOTE (EVENTS, print_keysym_tab ());
}
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
GdkKeymap*
_gdk_win32_display_get_keymap (GdkDisplay *display)
{
g_return_val_if_fail (display == gdk_display_get_default (), NULL);
Changes multihead reorganizing code for win32 support, mostly from a patch Wed Jun 5 18:34:47 2002 Owen Taylor <otaylor@redhat.com> Changes multihead reorganizing code for win32 support, mostly from a patch by Hans Breuer. * gdk/gdkcolor.c gdk/x11/gdkcolor-x11.c gdk/gdkcursor.c gdk/x11/gdkcursor-x11.c gdk/gdkevents.c gdk/x11/gdkevents-x11.c gdk/gdkfont.c gdk/x11/gdkfont-x11.c gdk/gdkkeys.c gdk/x11/gdkkeys-x11.c gdk/gdkimage.c gdk/x11/gdkimage-x11.c gdk/gdkscreen.c gdk/x11/gdkmain-x11.c gdk/gdkdisplay.c gdk/gdkevents-x11.c gdk/gdkpango.c gdk/x11/gdkpango-x11.c gdk/gdkselection.c gdk/x11/gdkselection-x11.c gdk/gdkwindow.c gdk/x11/gdkwindow-x11.c gdk/gdkvisual.c gdk/x11/gdkvisual-x11.c: Move port-independent singlehead wrapper functions into port-independent part of GDK. (#80009) * gdk/win32/gdkcolor-win32.c gdk/win32/gdkcursor-win32.c gdk/win32/gdkevents-win32.c gdk/win32/gdkfont-win32.c gdk/win32/gdkimage-win32.c gdk/win32/gdkkeys-win32.c gdk/win32/gdkmain-win32.c gdk/win32/gdkproperty-win32.c gdk/win32/gdkselection-win32.c gdk/win32/gkwindow-win32.c: Turn singlehead functions into "multihead" functions that ignore their GdkDisplay or GdkScreen arguments. * gdk/win32/gdkdrawable-win32.c gdk/win32/gdkevents-win32.c gdk/win32/gdkinput-win32.c gdk/win32/gdkprivate-win32.h: Misc multihead-compatibility changes. * gtk/gtk.def gdk/gdk.def: Update for multihead functions. * gdk/gdkcolormap.h gdk/gdkvisual.h gdk/x11/gdkcolormap-x11.c gdk/x11/gdkvisual-x11.c: Remove the screen fields from the public parts of the colormap/visual structures, add accessors instead. * gdk/gdkpixbuf-render.c gdk/gdkpixmap.c gdk/gdkrgb.c gdk/x11/gdkcolormap-x11.c gdk/x11/gdkimage-x11.c gdk/x11/gdkimage-x11.c gdk/x11/gdkprivate-x11.h gtk/gtkgc.c gtk/gtkstyle.c gtk/gtkwidget.c: Use accessors to get the screen for colormaps, visuals; move the fields into the private structures for the x11 backend. * gdk/gdkdisplay.[ch] gdk/x11/gdkdisplay-x11.[ch] gdk/gdkscreen.[ch] gdk/x11/gdkscreen-x11.c: Remove virtualization of screen and display functions. (#79990, patch from Erwann Chenede) * gdk/win32/gdkdisplay-x11.c gdk/win32/gdkscreen-win32.c gdk/win32/{Makefile.am, makefile.msc, makefile.mingw}: New files containing stub implementations of Display, Screen functions. * gdk/x11/gdkscreen-x11.[ch] gdk/x11/gdkdisplay-x11.[ch] gdk/x11/gdkx.h: Clean up function exports and what headers they are in. (#79954) * gdk/x11/gdkx.h: Fix macro that was referring to a non-existant screen->screen_num. (In the patch for #79972, Erwann Chenede) * gdk/gdkscreen.c gdk/gdkwindow.c gdk/x11/gdkinternals.h gdk/x11/gdkscreen-x11.c: Fix gdk_screen_get_window_at_pointer() to use window hooks. (#79972, patch partly from Erwann Chenede) * gdk/x11/gdkdisplay-x11.c gdk/x11/gdkevents-x11.c: Fix some warnings.
2002-06-06 00:26:42 +00:00
if (default_keymap == NULL)
default_keymap = g_object_new (gdk_win32_keymap_get_type (), NULL);
return default_keymap;
}
static PangoDirection
gdk_win32_keymap_get_direction (GdkKeymap *keymap)
{
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
update_keymap ();
switch (PRIMARYLANGID (LOWORD ((DWORD) (gintptr) _gdk_input_locale)))
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
{
case LANG_HEBREW:
case LANG_ARABIC:
#ifdef LANG_URDU
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
case LANG_URDU:
#endif
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
case LANG_FARSI:
/* Others? */
return PANGO_DIRECTION_RTL;
default:
return PANGO_DIRECTION_LTR;
}
}
static gboolean
gdk_win32_keymap_have_bidi_layouts (GdkKeymap *keymap)
{
/* Should we check if the kayboard layouts switchable at the moment
* cover both directionalities? What does the doc comment in
* ../x11/gdkkeys-x11.c exactly mean?
*/
return FALSE;
}
static gboolean
gdk_win32_keymap_get_caps_lock_state (GdkKeymap *keymap)
{
return ((GetKeyState (VK_CAPITAL) & 1) != 0);
}
static gboolean
gdk_win32_keymap_get_num_lock_state (GdkKeymap *keymap)
{
return ((GetKeyState (VK_NUMLOCK) & 1) != 0);
}
static gboolean
gdk_win32_keymap_get_scroll_lock_state (GdkKeymap *keymap)
{
return ((GetKeyState (VK_SCROLL) & 1) != 0);
}
static gboolean
gdk_win32_keymap_get_entries_for_keyval (GdkKeymap *keymap,
guint keyval,
GdkKeymapKey **keys,
gint *n_keys)
{
GArray *retval;
g_return_val_if_fail (keymap == NULL || GDK_IS_KEYMAP (keymap), FALSE);
g_return_val_if_fail (keys != NULL, FALSE);
g_return_val_if_fail (n_keys != NULL, FALSE);
g_return_val_if_fail (keyval != 0, FALSE);
retval = g_array_new (FALSE, FALSE, sizeof (GdkKeymapKey));
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
/* Accept only the default keymap */
if (keymap == NULL || keymap == gdk_keymap_get_default ())
{
gint vk;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
update_keymap ();
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
{
gint i;
for (i = 0; i < 4; i++)
{
if (keysym_tab[vk*4+i] == keyval)
{
GdkKeymapKey key;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
key.keycode = vk;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
/* 2 levels (normal, shift), two groups (normal, AltGr) */
key.group = i / 2;
key.level = i % 2;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
g_array_append_val (retval, key);
}
}
}
}
#ifdef G_ENABLE_DEBUG
if (_gdk_debug_flags & GDK_DEBUG_EVENTS)
{
gint i;
g_print ("gdk_keymap_get_entries_for_keyval: %#.04x (%s):",
keyval, gdk_keyval_name (keyval));
for (i = 0; i < retval->len; i++)
{
GdkKeymapKey *entry = (GdkKeymapKey *) retval->data + i;
g_print (" %#.02x %d %d", entry->keycode, entry->group, entry->level);
}
g_print ("\n");
}
#endif
if (retval->len > 0)
{
*keys = (GdkKeymapKey*) retval->data;
*n_keys = retval->len;
}
else
{
*keys = NULL;
*n_keys = 0;
}
g_array_free (retval, retval->len > 0 ? FALSE : TRUE);
return *n_keys > 0;
}
static gboolean
gdk_win32_keymap_get_entries_for_keycode (GdkKeymap *keymap,
guint hardware_keycode,
GdkKeymapKey **keys,
guint **keyvals,
gint *n_entries)
{
GArray *key_array;
GArray *keyval_array;
g_return_val_if_fail (keymap == NULL || GDK_IS_KEYMAP (keymap), FALSE);
g_return_val_if_fail (n_entries != NULL, FALSE);
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (hardware_keycode <= 0 ||
hardware_keycode >= KEY_STATE_SIZE)
{
if (keys)
*keys = NULL;
if (keyvals)
*keyvals = NULL;
*n_entries = 0;
return FALSE;
}
if (keys)
key_array = g_array_new (FALSE, FALSE, sizeof (GdkKeymapKey));
else
key_array = NULL;
if (keyvals)
keyval_array = g_array_new (FALSE, FALSE, sizeof (guint));
else
keyval_array = NULL;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
/* Accept only the default keymap */
if (keymap == NULL || keymap == gdk_keymap_get_default ())
{
gint i;
update_keymap ();
for (i = 0; i < 4; i++)
{
if (key_array)
{
GdkKeymapKey key;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
key.keycode = hardware_keycode;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
key.group = i / 2;
key.level = i % 2;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
g_array_append_val (key_array, key);
}
if (keyval_array)
g_array_append_val (keyval_array, keysym_tab[hardware_keycode*4+i]);
}
}
if ((key_array && key_array->len > 0) ||
(keyval_array && keyval_array->len > 0))
{
if (keys)
*keys = (GdkKeymapKey*) key_array->data;
if (keyvals)
*keyvals = (guint*) keyval_array->data;
if (key_array)
*n_entries = key_array->len;
else
*n_entries = keyval_array->len;
}
else
{
if (keys)
*keys = NULL;
if (keyvals)
*keyvals = NULL;
*n_entries = 0;
}
if (key_array)
g_array_free (key_array, key_array->len > 0 ? FALSE : TRUE);
if (keyval_array)
g_array_free (keyval_array, keyval_array->len > 0 ? FALSE : TRUE);
return *n_entries > 0;
}
static guint
gdk_win32_keymap_lookup_key (GdkKeymap *keymap,
const GdkKeymapKey *key)
{
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
guint sym;
g_return_val_if_fail (keymap == NULL || GDK_IS_KEYMAP (keymap), 0);
g_return_val_if_fail (key != NULL, 0);
g_return_val_if_fail (key->group < 4, 0);
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
/* Accept only the default keymap */
if (keymap != NULL && keymap != gdk_keymap_get_default ())
return 0;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
update_keymap ();
if (key->keycode >= KEY_STATE_SIZE ||
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
key->group < 0 || key->group >= 2 ||
key->level < 0 || key->level >= 2)
return 0;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
sym = keysym_tab[key->keycode*4 + key->group*2 + key->level];
2010-09-09 11:35:20 +00:00
if (sym == GDK_KEY_VoidSymbol)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
return 0;
else
return sym;
}
static gboolean
gdk_win32_keymap_translate_keyboard_state (GdkKeymap *keymap,
guint hardware_keycode,
GdkModifierType state,
gint group,
guint *keyval,
gint *effective_group,
gint *level,
Implement "fuzzy" key binding lookups; allow matches on key and level but Wed Feb 20 14:26:47 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkkeyhash.[ch]: Implement "fuzzy" key binding lookups; allow matches on key and level but not group. Also, implement ignoring "consumed modifiers correctly." * gtk/gtkaccelgroup.c gtk/gtkbindings.c: Convert to using GtkKeyHash. * gtk/gtkdebug.h gtk/gtkmain.c: Support GTK_DEBUG=keybindings * gdk/x11/gdkevents-x11.c (gdk_event_translate): Fill in the group for key release events as well as key press events. * gdk/gdkkeys.h gdk/x11/gdkkeys-x11.c (gdk_keymap_translate_keyboard_state): Rename unused_modifiers to consumed_modifiers, make the docs and non-Xkb implementation match the Xkb implementation. * gdk/linux-fb/gdkkeyboard-fb.c gdk/win32/gdkkeys-win32.c: Propagate doc and parameter name changes. * gdk/x11/gdkkeys-x11.c (gdk_keymap_translate_keyboard_state): XkbTranslateKeyCode doesn't handle LockMask, we need to handle it ourselves. * gdk/x11/gdkkeys-x11.c (gdk_keymap_translate_keyboard_state): Force <Shift>Tab to give GDK_ISO_Left_Tab, since we need consistency to allow dealing with ISO_Left_Tab. * gtk/gtkwindow.c gtk/gtktextview.c gtk/gtkscrolledwindow.c gtk/gtkpaned.c gtk/gtkcombo.c gtk/gtknotebook.c: Remove inappropriate uses of GDK_ISO_Left_Tab. (GDK_ISO_Left_Tab or <Shift>Tab both are equivalent as a binding specifier.) * gtk/gtkbutton.c (gtk_button_class_init): Make ::activate GTK_RUN_ACTION, so you can bind an accelerator to it. * gtk/gtklabel.c (gtk_label_set_uline_text_internal): Call gdk_unicode_to_keyval on the mnemonic character. * tests/testgtk.c: Add a test for the new fuzzy key binding matching.
2002-02-21 17:14:10 +00:00
GdkModifierType *consumed_modifiers)
{
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
guint tmp_keyval;
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
guint *keyvals;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
gint shift_level;
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
gboolean ignore_shift = FALSE;
gboolean ignore_group = FALSE;
g_return_val_if_fail (keymap == NULL || GDK_IS_KEYMAP (keymap), FALSE);
g_return_val_if_fail (group < 4, FALSE);
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#if 0
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
GDK_NOTE (EVENTS, g_print ("gdk_keymap_translate_keyboard_state: keycode=%#x state=%#x group=%d\n",
hardware_keycode, state, group));
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#endif
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (keyval)
*keyval = 0;
if (effective_group)
*effective_group = 0;
if (level)
*level = 0;
if (consumed_modifiers)
*consumed_modifiers = 0;
/* Accept only the default keymap */
if (keymap != NULL && keymap != gdk_keymap_get_default ())
return FALSE;
if (hardware_keycode >= KEY_STATE_SIZE)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
return FALSE;
if (group < 0 || group >= 2)
return FALSE;
update_keymap ();
keyvals = keysym_tab + hardware_keycode*4;
if ((state & GDK_LOCK_MASK) &&
(state & GDK_SHIFT_MASK) &&
((gdk_shift_modifiers & GDK_LOCK_MASK) ||
(keyvals[group*2 + 1] == gdk_keyval_to_upper (keyvals[group*2 + 0]))))
/* Shift always disables ShiftLock. Shift disables CapsLock for
* keys with lowercase/uppercase letter pairs.
*/
shift_level = 0;
else if (state & gdk_shift_modifiers)
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
shift_level = 1;
else
shift_level = 0;
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
/* Drop group and shift if there are no keysymbols on
* the key for those.
*/
if (shift_level == 1 &&
2010-09-09 11:35:20 +00:00
keyvals[group*2 + 1] == GDK_KEY_VoidSymbol &&
keyvals[group*2] != GDK_KEY_VoidSymbol)
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
{
shift_level = 0;
ignore_shift = TRUE;
}
if (group == 1 &&
2010-09-09 11:35:20 +00:00
keyvals[2 + shift_level] == GDK_KEY_VoidSymbol &&
keyvals[0 + shift_level] != GDK_KEY_VoidSymbol)
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
{
group = 0;
ignore_group = TRUE;
}
2010-09-09 11:35:20 +00:00
if (keyvals[group *2 + shift_level] == GDK_KEY_VoidSymbol &&
keyvals[0 + 0] != GDK_KEY_VoidSymbol)
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
{
shift_level = 0;
group = 0;
ignore_group = TRUE;
ignore_shift = TRUE;
}
/* See whether the group and shift level actually mattered
* to know what to put in consumed_modifiers
*/
2010-09-09 11:35:20 +00:00
if (keyvals[group*2 + 1] == GDK_KEY_VoidSymbol ||
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
keyvals[group*2 + 0] == keyvals[group*2 + 1])
ignore_shift = TRUE;
2010-09-09 11:35:20 +00:00
if (keyvals[2 + shift_level] == GDK_KEY_VoidSymbol ||
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
keyvals[0 + shift_level] == keyvals[2 + shift_level])
ignore_group = TRUE;
tmp_keyval = keyvals[group*2 + shift_level];
/* If a true CapsLock is toggled, and Shift is not down,
* and the shifted keysym is the uppercase of the unshifted,
* use it.
*/
if (!(gdk_shift_modifiers & GDK_LOCK_MASK) &&
!(state & GDK_SHIFT_MASK) &&
(state & GDK_LOCK_MASK))
{
guint upper = gdk_keyval_to_upper (tmp_keyval);
if (upper == keyvals[group*2 + 1])
tmp_keyval = upper;
}
if (keyval)
*keyval = tmp_keyval;
if (effective_group)
*effective_group = group;
Implement the functions that until now just were non-functional stubs. For 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-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.
2002-02-26 01:18:27 +00:00
if (level)
*level = shift_level;
if (consumed_modifiers)
{
*consumed_modifiers =
(ignore_group ? 0 : GDK_MOD2_MASK) |
(ignore_shift ? 0 : (GDK_SHIFT_MASK|GDK_LOCK_MASK));
}
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#if 0
GDK_NOTE (EVENTS, g_print ("... group=%d level=%d cmods=%#x keyval=%s\n",
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
group, shift_level, tmp_modifiers, gdk_keyval_name (tmp_keyval)));
Merge from stable: 2003-12-14 Tor Lillqvist <tml@iki.fi> Merge from stable: * gdk/gdkdisplaymanager.c: Mark default_display static. * gdk/win32/gdkdnd-win32.c: Mark current_dest_drag static. * gdk/win32/gdkkeys-win32.c: Disable some overly verbose debugging output. * gdk/win32/gdkevents-win32.c: Clean up the debugging output from --gdk-debug=events. In general, output just one line of debugging output for each Windows message, plus one line for each GDK event generated. Indent all lines according to window procedure nesting level. (inner_window_procedure): Rename from real_window_procedure. (find_real_window_for_grabbed_mouse_event): Don't get misled when the point is in the non-client (decoration) area of the window returned by WindowFromPoint(). Return the root window in that case. (build_pointer_event_state): Test also MK_XBUTTON1 and MK_XBUTTON2 (buttons 4 and 5). (synthesize_enter_event): Track the mouse leaving the window in the event being generated, not the one mentioned in the Windows message. (propagate): Test for NULL parent earlier. Improves event generation from a grabbed pointer. Part of fix for #107320. (handle_stuff_while_moving_or_resizing): New function, to dispatch the main loop (once). (resize_timer_proc): New function, set to be called by an inerval timer during resizes/moves. Calls handle_stuff_while_moving_or_resizing(). (gdk_event_translate): Drop unused return_exposes parameter. Handle WM_XBUTTONDOWN and UP messages (buttons 4 and 5). On WM_SYSKEYUP, generate a key release event also for just the Alt key. On WM_MOUSELEAVE, generate a leave event of type GDK_NOTIFY_ANCESTOR (and not UNKNOWN) if the mouse left a top-level window, and left the app completely. On WM_ENTERSIZEMOVE, set a flag, and start an interval timer that calls resize_timer_proc() at regular intervals. On WM_EXITSIZEMOVE, kill the timer. On WM_WINDOWPOSCHANGED, generate a configure event if necessary, and dispatch the main loop (by calling handle_stuff_while_moving_or_resizing()). Fixes #99540, idea by Herman Bloggs. * gdk/win32/gdkmain-win32.c (_gdk_win32_message_to_string): Handle also wintab messages. * gdk/win32/gdkwindow-win32.c (gdk_window_set_skip_taskbar_hint): Instead of using WS_EX_TOOLWINDOW, implement by setting/unsetting the window's owner. Fixes #118093, reported by Maxime Romano.
2003-12-14 01:57:54 +00:00
#endif
Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they 2002-03-06 Tor Lillqvist <tml@iki.fi> * gdk/win32/gdkevents-win32.c (gdk_pointer_grab, gdk_pointer_ungrab): Bypass calls to the grab/ungrab functions in gdkinput-win32.c, as they don't effectively do anything anyway. (build_key_event_state): Set MOD2 bit if key is in AltGr group. (gdk_event_translate): Call _gdk_windowing_window_get_offsets() each time the offsets are used, on the window they refer to, instead of once in the beginning. The window in question might change due to event propagation. (gdk_event_translate): Set key event group to 0 for non-AltGr keys. Do set the SHIFT bit in the key event state also for ISO_Left_Tab. Now backtabbing finally works again. * gdk/win32/gdkunput-win32.c: Minor debugging output change. * gdk/win32/gdkkeys-win32.c (update_keymap): Set VK_TAB mapping to Gdk_Tab and GDK_ISO_Left_Tab, like on X11. (gdk_keymap_translate_keyboard_state): Add similar code as in the non-XKB case on X11 to generate a more correct consumed_modifiers. Add debugging output. (gdk_keyval_name): Use the U+xxxx format for UCS characters encoded as keyvals. Never return NULL, but hex number representation if keyval not in table. * gdk/win32/gdkwindow-win32.c (gdk_window_focus): Call SetFocus(). Doesn't seem to have any harmful effect, and probably is close to what this function is supposed to do. But it didn't fix GtkCombo as I had hoped. (gdk_window_set_type_hint): Don't intern the _NET_WM_* atoms that weren't used and wouldn't have any meaning on Win32 anyway.
2002-03-06 00:36:08 +00:00
2010-09-09 11:35:20 +00:00
return tmp_keyval != GDK_KEY_VoidSymbol;
}
static void
gdk_win32_keymap_add_virtual_modifiers (GdkKeymap *keymap,
GdkModifierType *state)
{
}
static gboolean
gdk_win32_keymap_map_virtual_modifiers (GdkKeymap *keymap,
GdkModifierType *state)
{
/* FIXME: Is this the right thing to do? */
return TRUE;
}
static void
gdk_win32_keymap_finalize (GObject *object)
{
}
static void
gdk_win32_keymap_class_init (GdkWin32KeymapClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
GdkKeymapClass *keymap_class = GDK_KEYMAP_CLASS (klass);
object_class->finalize = gdk_win32_keymap_finalize;
keymap_class->get_direction = gdk_win32_keymap_get_direction;
keymap_class->have_bidi_layouts = gdk_win32_keymap_have_bidi_layouts;
keymap_class->get_caps_lock_state = gdk_win32_keymap_get_caps_lock_state;
keymap_class->get_num_lock_state = gdk_win32_keymap_get_num_lock_state;
keymap_class->get_scroll_lock_state = gdk_win32_keymap_get_scroll_lock_state;
keymap_class->get_entries_for_keyval = gdk_win32_keymap_get_entries_for_keyval;
keymap_class->get_entries_for_keycode = gdk_win32_keymap_get_entries_for_keycode;
keymap_class->lookup_key = gdk_win32_keymap_lookup_key;
keymap_class->translate_keyboard_state = gdk_win32_keymap_translate_keyboard_state;
keymap_class->add_virtual_modifiers = gdk_win32_keymap_add_virtual_modifiers;
keymap_class->map_virtual_modifiers = gdk_win32_keymap_map_virtual_modifiers;
}