2000-12-14 23:14:18 +00:00
|
|
|
/* 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/>.
|
2000-12-14 23:14:18 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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/.
|
|
|
|
|
*/
|
2013-05-30 08:07:31 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
|
2000-12-14 23:14:18 +00:00
|
|
|
#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"
|
2011-01-02 10:51:25 +00:00
|
|
|
#include "gdkkeysprivate.h"
|
|
|
|
|
#include "gdkwin32keys.h"
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2020-04-06 19:13:00 +00:00
|
|
|
#define GDK_MOD2_MASK (1 << 4)
|
|
|
|
|
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
enum _GdkWin32KeyLevelState
|
|
|
|
|
{
|
|
|
|
|
GDK_WIN32_LEVEL_NONE = 0,
|
|
|
|
|
GDK_WIN32_LEVEL_SHIFT,
|
2017-01-04 04:31:53 +00:00
|
|
|
GDK_WIN32_LEVEL_CAPSLOCK,
|
|
|
|
|
GDK_WIN32_LEVEL_SHIFT_CAPSLOCK,
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
GDK_WIN32_LEVEL_ALTGR,
|
|
|
|
|
GDK_WIN32_LEVEL_SHIFT_ALTGR,
|
2017-01-04 04:31:53 +00:00
|
|
|
GDK_WIN32_LEVEL_CAPSLOCK_ALTGR,
|
|
|
|
|
GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR,
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
GDK_WIN32_LEVEL_COUNT
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef enum _GdkWin32KeyLevelState GdkWin32KeyLevelState;
|
|
|
|
|
|
|
|
|
|
struct _GdkWin32KeyNode
|
|
|
|
|
{
|
|
|
|
|
/* Non-spacing version of the dead key */
|
|
|
|
|
guint undead_gdk_keycode;
|
|
|
|
|
|
|
|
|
|
/* Virtual key code */
|
|
|
|
|
guint8 vk;
|
|
|
|
|
|
|
|
|
|
/* Level for which this virtual key code produces this gdk_keycode */
|
|
|
|
|
GdkWin32KeyLevelState level;
|
|
|
|
|
|
|
|
|
|
/* GDK (X11) code for this key */
|
|
|
|
|
guint gdk_keycode;
|
|
|
|
|
|
|
|
|
|
/* Array of GdkWin32KeyNode should be sorted by gdk_keycode, then by level */
|
|
|
|
|
GArray *combinations;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct _GdkWin32KeyNode GdkWin32KeyNode;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
Example:
|
|
|
|
|
GdkWin32KeyNode
|
|
|
|
|
{
|
|
|
|
|
undead_gdk_keycode = 0x0b4 GDK_KEY_acute (')
|
|
|
|
|
vk = 0xde VK_OEM_7
|
|
|
|
|
level = GDK_WIN32_LEVEL_NONE
|
|
|
|
|
gdk_keycode = 0xfe51 GDK_KEY_dead_acute
|
|
|
|
|
combinations =
|
|
|
|
|
{
|
|
|
|
|
GdkWin32KeyNode
|
|
|
|
|
{
|
|
|
|
|
undead_gdk_keycode = 0x061 GDK_KEY_a (a)
|
|
|
|
|
level = GDK_WIN32_LEVEL_NONE
|
|
|
|
|
vk = 0x41 VK_A
|
|
|
|
|
gdk_keycode = 0xe1 GDK_KEY_aacute á
|
|
|
|
|
combinations = NULL
|
|
|
|
|
},
|
|
|
|
|
GdkWin32KeyNode
|
|
|
|
|
{
|
|
|
|
|
unicode_char = 0x041 GDK_KEY_A (A)
|
|
|
|
|
level = GDK_WIN32_LEVEL_SHIFT
|
|
|
|
|
vk = 0x41 VK_A
|
|
|
|
|
gdk_keycode = 0x0c1 GDK_KEY_Aacute Á
|
|
|
|
|
combinations = NULL
|
|
|
|
|
},
|
|
|
|
|
{ ... }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Thus:
|
|
|
|
|
|
|
|
|
|
GDK_KEY_dead_acute + GDK_KEY_a
|
|
|
|
|
= GDK_KEY_aacute
|
|
|
|
|
|
|
|
|
|
GDK_KEY_dead_acute + GDK_KEY_A
|
|
|
|
|
= GDK_KEY_Aacute
|
|
|
|
|
|
|
|
|
|
GDK_KEY_dead_acute + GDK_KEY_s
|
|
|
|
|
matches partially
|
|
|
|
|
(GDK_KEY_dead_acute is a known dead key, but does not combine with GDK_KEY_s)
|
|
|
|
|
and resolves into:
|
|
|
|
|
GDK_KEY_acute + GDK_KEY_s
|
|
|
|
|
|
|
|
|
|
GDK_KEY_dead_somethingelse + GDK_KEY_anything
|
|
|
|
|
does not match at all
|
|
|
|
|
(W32 API did not provide any deadkey info for GDK_KEY_dead_somethingelse)
|
|
|
|
|
and the caller will try other matching mechanisms for compose_buffer
|
|
|
|
|
*/
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
struct _GdkWin32KeyGroupOptions
|
|
|
|
|
{
|
|
|
|
|
/* character that should be used as the decimal separator */
|
|
|
|
|
wchar_t decimal_mark;
|
|
|
|
|
|
|
|
|
|
/* Scancode for the VK_RSHIFT */
|
|
|
|
|
guint scancode_rshift;
|
|
|
|
|
|
|
|
|
|
/* TRUE if Ctrl+Alt emulates AltGr */
|
|
|
|
|
gboolean has_altgr;
|
|
|
|
|
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
GArray *dead_keys;
|
2016-07-13 11:41:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct _GdkWin32KeyGroupOptions GdkWin32KeyGroupOptions;
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
struct _GdkWin32KeymapClass
|
|
|
|
|
{
|
|
|
|
|
GdkKeymapClass parent_class;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GdkWin32Keymap
|
|
|
|
|
{
|
|
|
|
|
GdkKeymap parent_instance;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
/* length = what GetKeyboardLayoutList() returns, type = HKL.
|
|
|
|
|
* When it changes, recreate the keymap and repopulate the options.
|
|
|
|
|
*/
|
|
|
|
|
GArray *layout_handles;
|
|
|
|
|
|
|
|
|
|
/* VirtualKeyCode -> gdk_keyval table
|
2017-01-04 04:31:53 +00:00
|
|
|
* length = 256 * length(layout_handles) * 2 * 4
|
2016-07-13 11:41:35 +00:00
|
|
|
* 256 is the number of virtual key codes,
|
2017-01-04 04:31:53 +00:00
|
|
|
* 2x4 is the number of Shift/AltGr/CapsLock combinations (level),
|
2016-07-13 11:41:35 +00:00
|
|
|
* length(layout_handles) is the number of layout handles (group).
|
|
|
|
|
*/
|
|
|
|
|
guint *keysym_tab;
|
|
|
|
|
|
|
|
|
|
/* length = length(layout_handles), type = GdkWin32KeyGroupOptions
|
|
|
|
|
* Kept separate from layout_handles because layout_handles is
|
|
|
|
|
* populated by W32 API.
|
|
|
|
|
*/
|
|
|
|
|
GArray *options;
|
|
|
|
|
|
|
|
|
|
/* Index of a handle in layout_handles,
|
|
|
|
|
* at any point it should be the same handle as GetKeyboardLayout(0) returns,
|
|
|
|
|
* but GDK caches it to avoid calling GetKeyboardLayout (0) every time.
|
|
|
|
|
*/
|
|
|
|
|
guint8 active_layout;
|
|
|
|
|
};
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
G_DEFINE_TYPE (GdkWin32Keymap, gdk_win32_keymap, GDK_TYPE_KEYMAP)
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
guint _gdk_keymap_serial = 0;
|
|
|
|
|
|
|
|
|
|
static GdkKeymap *default_keymap = NULL;
|
|
|
|
|
|
|
|
|
|
#define KEY_STATE_SIZE 256
|
|
|
|
|
|
|
|
|
|
static void update_keymap (GdkKeymap *gdk_keymap);
|
|
|
|
|
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
static void
|
|
|
|
|
gdk_win32_key_group_options_clear (GdkWin32KeyGroupOptions *options)
|
|
|
|
|
{
|
|
|
|
|
g_clear_pointer (&options->dead_keys, g_array_unref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
gdk_win32_key_node_clear (GdkWin32KeyNode *node)
|
|
|
|
|
{
|
|
|
|
|
g_clear_pointer (&node->combinations, g_array_unref);
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static void
|
|
|
|
|
gdk_win32_keymap_init (GdkWin32Keymap *keymap)
|
|
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
keymap->layout_handles = g_array_new (FALSE, FALSE, sizeof (HKL));
|
|
|
|
|
keymap->options = g_array_new (FALSE, FALSE, sizeof (GdkWin32KeyGroupOptions));
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
g_array_set_clear_func (keymap->options, (GDestroyNotify) gdk_win32_key_group_options_clear);
|
2016-07-13 11:41:35 +00:00
|
|
|
keymap->keysym_tab = NULL;
|
|
|
|
|
keymap->active_layout = 0;
|
|
|
|
|
update_keymap (GDK_KEYMAP (keymap));
|
2011-01-02 10:51:25 +00:00
|
|
|
}
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
static void
|
|
|
|
|
gdk_win32_keymap_finalize (GObject *object)
|
|
|
|
|
{
|
|
|
|
|
GdkWin32Keymap *keymap = GDK_WIN32_KEYMAP (object);
|
2001-06-22 14:08:51 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_clear_pointer (&keymap->keysym_tab, g_free);
|
|
|
|
|
g_clear_pointer (&keymap->layout_handles, g_array_unref);
|
|
|
|
|
g_clear_pointer (&keymap->options, g_array_unref);
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
G_OBJECT_CLASS (gdk_win32_keymap_parent_class)->finalize (object);
|
|
|
|
|
}
|
2014-08-13 18:43:51 +00:00
|
|
|
|
2002-09-11 21:55:48 +00:00
|
|
|
#ifdef G_ENABLE_DEBUG
|
|
|
|
|
static void
|
2016-07-13 11:41:35 +00:00
|
|
|
print_keysym_tab (GdkWin32Keymap *keymap)
|
2002-09-11 21:55:48 +00:00
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int li;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32KeyGroupOptions *options;
|
2020-07-24 13:54:49 +00:00
|
|
|
int vk;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32KeyLevelState level;
|
2020-07-24 13:54:49 +00:00
|
|
|
int group_size = keymap->layout_handles->len;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
for (li = 0; li < group_size; li++)
|
2002-09-11 21:55:48 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
options = &g_array_index (keymap->options, GdkWin32KeyGroupOptions, li);
|
2017-01-04 04:31:53 +00:00
|
|
|
g_print ("keymap %d (0x%p):%s\n",
|
2016-07-13 11:41:35 +00:00
|
|
|
li, g_array_index (keymap->layout_handles, HKL, li),
|
2017-01-04 04:31:53 +00:00
|
|
|
options->has_altgr ? " (uses AltGr)" : "");
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
|
|
|
|
|
{
|
|
|
|
|
g_print ("%#.02x: ", vk);
|
|
|
|
|
|
|
|
|
|
for (level = 0; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
{
|
2020-02-10 03:58:53 +00:00
|
|
|
const char *name = gdk_keyval_name (keymap->keysym_tab[vk * group_size * GDK_WIN32_LEVEL_COUNT + level]);
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
g_print ("%s ", name ? name : "(none)");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
g_print ("\n");
|
|
|
|
|
}
|
2002-09-11 21:55:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-02-01 11:26:05 +00:00
|
|
|
static void
|
|
|
|
|
handle_special (guint vk,
|
|
|
|
|
guint *ksymp,
|
2020-07-24 13:54:49 +00:00
|
|
|
int shift)
|
2005-02-01 11:26:05 +00:00
|
|
|
|
|
|
|
|
{
|
|
|
|
|
switch (vk)
|
|
|
|
|
{
|
|
|
|
|
case VK_CANCEL:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Cancel; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_BACK:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_BackSpace; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_TAB:
|
|
|
|
|
if (shift & 0x1)
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_ISO_Left_Tab;
|
2005-02-01 11:26:05 +00:00
|
|
|
else
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Tab;
|
2005-02-01 11:26:05 +00:00
|
|
|
break;
|
|
|
|
|
case VK_CLEAR:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Clear; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RETURN:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Return; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_SHIFT:
|
|
|
|
|
case VK_LSHIFT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Shift_L; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_CONTROL:
|
|
|
|
|
case VK_LCONTROL:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Control_L; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_MENU:
|
|
|
|
|
case VK_LMENU:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Alt_L; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_PAUSE:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Pause; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_ESCAPE:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Escape; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_PRIOR:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Prior; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_NEXT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Next; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_END:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_End; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_HOME:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Home; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_LEFT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Left; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_UP:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Up; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RIGHT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Right; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_DOWN:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Down; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_SELECT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Select; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_PRINT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Print; break;
|
2012-10-15 16:07:46 +00:00
|
|
|
case VK_SNAPSHOT:
|
|
|
|
|
*ksymp = GDK_KEY_Print; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_EXECUTE:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Execute; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_INSERT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Insert; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_DELETE:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Delete; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_HELP:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Help; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_LWIN:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Meta_L; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RWIN:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Meta_R; break;
|
2005-05-22 22:28:39 +00:00
|
|
|
case VK_APPS:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Menu; break;
|
2015-05-01 11:03:49 +00:00
|
|
|
case VK_DECIMAL:
|
2015-05-04 15:32:22 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Decimal; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_MULTIPLY:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Multiply; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_ADD:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Add; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_SEPARATOR:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Separator; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_SUBTRACT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Subtract; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_DIVIDE:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_Divide; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD0:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_0; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD1:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_1; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD2:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_2; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD3:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_3; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD4:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_4; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD5:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_5; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD6:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_6; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD7:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_7; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD8:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_8; break;
|
2006-04-19 09:42:06 +00:00
|
|
|
case VK_NUMPAD9:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_KP_9; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F1:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F1; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F2:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F2; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F3:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F3; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F4:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F4; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F5:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F5; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F6:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F6; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F7:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F7; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F8:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F8; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F9:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F9; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F10:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F10; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F11:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F11; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F12:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F12; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F13:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F13; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F14:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F14; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F15:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F15; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F16:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F16; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F17:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F17; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F18:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F18; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F19:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F19; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F20:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F20; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F21:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F21; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F22:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F22; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F23:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F23; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_F24:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_F24; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_NUMLOCK:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Num_Lock; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_SCROLL:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Scroll_Lock; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RSHIFT:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Shift_R; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RCONTROL:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Control_R; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
case VK_RMENU:
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_Alt_R; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2016-07-13 11:41:35 +00:00
|
|
|
set_level_vks (guchar *key_state,
|
|
|
|
|
GdkWin32KeyLevelState level)
|
2005-02-01 11:26:05 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
switch (level)
|
2005-02-01 11:26:05 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_NONE:
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_SHIFT] = 0;
|
2017-01-04 04:31:53 +00:00
|
|
|
key_state[VK_CAPITAL] = 0;
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
|
|
|
|
|
break;
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_SHIFT:
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_SHIFT] = 0x80;
|
2017-01-04 04:31:53 +00:00
|
|
|
key_state[VK_CAPITAL] = 0;
|
|
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_CAPSLOCK:
|
|
|
|
|
key_state[VK_SHIFT] = 0;
|
|
|
|
|
key_state[VK_CAPITAL] = 0x01;
|
|
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_SHIFT_CAPSLOCK:
|
|
|
|
|
key_state[VK_SHIFT] = 0x80;
|
|
|
|
|
key_state[VK_CAPITAL] = 0x01;
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0;
|
|
|
|
|
break;
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_ALTGR:
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_SHIFT] = 0;
|
2017-01-04 04:31:53 +00:00
|
|
|
key_state[VK_CAPITAL] = 0;
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
|
|
|
|
|
break;
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_SHIFT_ALTGR:
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_SHIFT] = 0x80;
|
2017-01-04 04:31:53 +00:00
|
|
|
key_state[VK_CAPITAL] = 0;
|
|
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_CAPSLOCK_ALTGR:
|
|
|
|
|
key_state[VK_SHIFT] = 0;
|
|
|
|
|
key_state[VK_CAPITAL] = 0x01;
|
|
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR:
|
|
|
|
|
key_state[VK_SHIFT] = 0x80;
|
|
|
|
|
key_state[VK_CAPITAL] = 0x01;
|
2005-02-01 11:26:05 +00:00
|
|
|
key_state[VK_CONTROL] = key_state[VK_MENU] = 0x80;
|
|
|
|
|
break;
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_COUNT:
|
|
|
|
|
g_assert_not_reached ();
|
|
|
|
|
break;
|
2005-02-01 11:26:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2016-07-13 11:41:35 +00:00
|
|
|
reset_after_dead (guchar key_state[KEY_STATE_SIZE],
|
|
|
|
|
HKL handle)
|
2005-02-01 11:26:05 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
guchar temp_key_state[KEY_STATE_SIZE];
|
2006-08-29 23:01:53 +00:00
|
|
|
wchar_t wcs[2];
|
2005-02-01 11:26:05 +00:00
|
|
|
|
2014-08-13 18:43:51 +00:00
|
|
|
memmove (temp_key_state, key_state, KEY_STATE_SIZE);
|
2005-02-01 11:26:05 +00:00
|
|
|
|
|
|
|
|
temp_key_state[VK_SHIFT] =
|
|
|
|
|
temp_key_state[VK_CONTROL] =
|
2017-01-04 04:31:53 +00:00
|
|
|
temp_key_state[VK_CAPITAL] =
|
2005-02-01 11:26:05 +00:00
|
|
|
temp_key_state[VK_MENU] = 0;
|
|
|
|
|
|
2006-08-29 23:01:53 +00:00
|
|
|
ToUnicodeEx (VK_SPACE, MapVirtualKey (VK_SPACE, 0),
|
|
|
|
|
temp_key_state, wcs, G_N_ELEMENTS (wcs),
|
2016-07-13 11:41:35 +00:00
|
|
|
0, handle);
|
2005-02-01 11:26:05 +00:00
|
|
|
}
|
|
|
|
|
|
2005-05-22 21:23:45 +00:00
|
|
|
static void
|
2005-02-01 11:26:05 +00:00
|
|
|
handle_dead (guint keysym,
|
|
|
|
|
guint *ksymp)
|
|
|
|
|
{
|
|
|
|
|
switch (keysym)
|
|
|
|
|
{
|
|
|
|
|
case '"': /* 0x022 */
|
2010-09-09 11:35:20 +00:00
|
|
|
*ksymp = GDK_KEY_dead_diaeresis; break;
|
2005-02-01 11:26:05 +00:00
|
|
|
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;
|
2005-02-01 11:26:05 +00:00
|
|
|
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;
|
2005-02-01 11:26:05 +00:00
|
|
|
default:
|
2005-05-22 21:23:45 +00:00
|
|
|
/* 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;
|
2005-02-01 11:26:05 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-26 17:21:26 +00:00
|
|
|
/* keypad decimal mark depends on active keyboard layout
|
|
|
|
|
* return current decimal mark as unicode character
|
|
|
|
|
*/
|
|
|
|
|
guint32
|
2016-07-13 11:41:35 +00:00
|
|
|
_gdk_win32_keymap_get_decimal_mark (GdkWin32Keymap *keymap)
|
|
|
|
|
{
|
|
|
|
|
if (keymap != NULL &&
|
|
|
|
|
keymap->layout_handles->len > 0 &&
|
|
|
|
|
g_array_index (keymap->options, GdkWin32KeyGroupOptions, keymap->active_layout).decimal_mark)
|
|
|
|
|
return g_array_index (keymap->options, GdkWin32KeyGroupOptions, keymap->active_layout).decimal_mark;
|
|
|
|
|
|
|
|
|
|
return (guint32) '.';
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
2020-07-24 13:54:49 +00:00
|
|
|
layouts_are_the_same (GArray *array, HKL *hkls, int hkls_len)
|
2016-02-26 17:21:26 +00:00
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int i;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
if (hkls_len != array->len)
|
|
|
|
|
return FALSE;
|
2016-02-26 17:21:26 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
for (i = 0; i < hkls_len; i++)
|
|
|
|
|
if (hkls[i] != g_array_index (array, HKL, i))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
2016-02-26 17:21:26 +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
|
|
|
static void
|
2016-07-13 11:41:35 +00:00
|
|
|
check_that_active_layout_is_in_sync (GdkWin32Keymap *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
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
HKL hkl;
|
|
|
|
|
HKL cached_hkl;
|
|
|
|
|
wchar_t hkl_name[KL_NAMELENGTH];
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (keymap->layout_handles->len <= 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
|
|
|
return;
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
hkl = GetKeyboardLayout (0);
|
|
|
|
|
cached_hkl = g_array_index (keymap->layout_handles, HKL, keymap->active_layout);
|
|
|
|
|
|
|
|
|
|
if (hkl != cached_hkl)
|
|
|
|
|
{
|
|
|
|
|
if (!GetKeyboardLayoutNameW (hkl_name))
|
|
|
|
|
wcscpy_s (hkl_name, KL_NAMELENGTH, L"(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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_warning ("Cached active layout #%d (0x%p) does not match actual layout %S, 0x%p",
|
|
|
|
|
keymap->active_layout, cached_hkl, hkl_name, hkl);
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
|
2020-07-24 13:54:49 +00:00
|
|
|
static int
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
sort_key_nodes_by_gdk_keyval (gconstpointer a,
|
|
|
|
|
gconstpointer b)
|
|
|
|
|
{
|
|
|
|
|
const GdkWin32KeyNode *one = a;
|
|
|
|
|
const GdkWin32KeyNode *two = b;
|
|
|
|
|
|
|
|
|
|
if (one->gdk_keycode < two->gdk_keycode)
|
|
|
|
|
return -1;
|
|
|
|
|
else if (one->gdk_keycode > two->gdk_keycode)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if (one->level < two->level)
|
|
|
|
|
return -1;
|
|
|
|
|
else if (one->level > two->level)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
static void
|
|
|
|
|
update_keymap (GdkKeymap *gdk_keymap)
|
|
|
|
|
{
|
|
|
|
|
int hkls_len;
|
|
|
|
|
static int hkls_size = 0;
|
|
|
|
|
static HKL *hkls = NULL;
|
|
|
|
|
gboolean no_list;
|
|
|
|
|
static guint current_serial = 0;
|
2020-07-24 13:54:49 +00:00
|
|
|
int i, group;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32KeyLevelState level;
|
|
|
|
|
GdkWin32KeyGroupOptions *options;
|
|
|
|
|
GdkWin32Keymap *keymap = GDK_WIN32_KEYMAP (gdk_keymap);
|
2020-07-24 13:54:49 +00:00
|
|
|
int keysym_tab_size;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
guchar key_state[KEY_STATE_SIZE];
|
|
|
|
|
guint scancode;
|
|
|
|
|
guint vk;
|
|
|
|
|
guint *keygroup;
|
|
|
|
|
|
|
|
|
|
if (keymap->keysym_tab != NULL &&
|
|
|
|
|
current_serial == _gdk_keymap_serial)
|
|
|
|
|
return;
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
no_list = FALSE;
|
|
|
|
|
hkls_len = GetKeyboardLayoutList (0, NULL);
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (hkls_len <= 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
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
hkls_len = 1;
|
|
|
|
|
no_list = TRUE;
|
|
|
|
|
}
|
|
|
|
|
else if (hkls_len > 255)
|
|
|
|
|
{
|
|
|
|
|
hkls_len = 255;
|
|
|
|
|
}
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (hkls_size < hkls_len)
|
|
|
|
|
{
|
|
|
|
|
hkls = g_renew (HKL, hkls, hkls_len);
|
|
|
|
|
hkls_size = hkls_len;
|
|
|
|
|
}
|
2005-05-18 14:53:00 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (hkls_len != GetKeyboardLayoutList (hkls_len, hkls))
|
|
|
|
|
{
|
|
|
|
|
if (!no_list)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
hkls[0] = GetKeyboardLayout (0);
|
|
|
|
|
hkls_len = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (layouts_are_the_same (keymap->layout_handles, hkls, hkls_len))
|
|
|
|
|
{
|
|
|
|
|
check_that_active_layout_is_in_sync (keymap);
|
|
|
|
|
current_serial = _gdk_keymap_serial;
|
|
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
GDK_NOTE (EVENTS, g_print ("\nHave %d keyboard layouts:", hkls_len));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < hkls_len; i++)
|
|
|
|
|
{
|
|
|
|
|
GDK_NOTE (EVENTS, g_print (" 0x%p", hkls[i]));
|
|
|
|
|
|
|
|
|
|
if (GetKeyboardLayout (0) == hkls[i])
|
|
|
|
|
{
|
|
|
|
|
wchar_t hkl_name[KL_NAMELENGTH];
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (!GetKeyboardLayoutNameW (hkl_name))
|
|
|
|
|
wcscpy_s (hkl_name, KL_NAMELENGTH, L"(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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
GDK_NOTE (EVENTS, g_print ("(active, %S)", hkl_name));
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
GDK_NOTE (EVENTS, g_print ("\n"));
|
2005-02-01 11:26:05 +00:00
|
|
|
|
2017-01-04 04:31:53 +00:00
|
|
|
keysym_tab_size = hkls_len * 256 * 2 * 4;
|
2005-02-01 11:26:05 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (hkls_len != keymap->layout_handles->len)
|
|
|
|
|
keymap->keysym_tab = g_renew (guint, keymap->keysym_tab, keysym_tab_size);
|
|
|
|
|
|
|
|
|
|
memset (keymap->keysym_tab, 0, keysym_tab_size);
|
|
|
|
|
g_array_set_size (keymap->layout_handles, hkls_len);
|
|
|
|
|
g_array_set_size (keymap->options, hkls_len);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < hkls_len; i++)
|
|
|
|
|
{
|
|
|
|
|
options = &g_array_index (keymap->options, GdkWin32KeyGroupOptions, i);
|
|
|
|
|
|
|
|
|
|
options->decimal_mark = 0;
|
|
|
|
|
options->scancode_rshift = 0;
|
|
|
|
|
options->has_altgr = FALSE;
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
options->dead_keys = g_array_new (FALSE, FALSE, sizeof (GdkWin32KeyNode));
|
|
|
|
|
g_array_set_clear_func (options->dead_keys, (GDestroyNotify) gdk_win32_key_node_clear);
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
g_array_index (keymap->layout_handles, HKL, i) = hkls[i];
|
|
|
|
|
|
|
|
|
|
if (hkls[i] == _gdk_input_locale)
|
|
|
|
|
keymap->active_layout = i;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
|
|
|
|
|
{
|
|
|
|
|
for (group = 0; group < hkls_len; group++)
|
|
|
|
|
{
|
|
|
|
|
options = &g_array_index (keymap->options, GdkWin32KeyGroupOptions, group);
|
|
|
|
|
scancode = MapVirtualKeyEx (vk, 0, hkls[group]);
|
|
|
|
|
keygroup = &keymap->keysym_tab[(vk * hkls_len + group) * GDK_WIN32_LEVEL_COUNT];
|
|
|
|
|
|
2016-07-27 18:05:10 +00:00
|
|
|
/* MapVirtualKeyEx() fails to produce a scancode for VK_DIVIDE and VK_PAUSE.
|
|
|
|
|
* Ignore that, handle_special() will figure out a Gdk keyval for these
|
|
|
|
|
* without needing a scancode.
|
|
|
|
|
*/
|
2016-07-13 11:41:35 +00:00
|
|
|
if (scancode == 0 &&
|
2016-07-27 18:05:10 +00:00
|
|
|
vk != VK_DIVIDE &&
|
|
|
|
|
vk != VK_PAUSE)
|
2016-07-13 11:41:35 +00:00
|
|
|
{
|
|
|
|
|
for (level = GDK_WIN32_LEVEL_NONE; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
keygroup[level] = GDK_KEY_VoidSymbol;
|
|
|
|
|
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vk == VK_RSHIFT)
|
|
|
|
|
options->scancode_rshift = scancode;
|
|
|
|
|
|
|
|
|
|
key_state[vk] = 0x80;
|
|
|
|
|
|
|
|
|
|
for (level = GDK_WIN32_LEVEL_NONE; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
{
|
|
|
|
|
guint *ksymp = &keygroup[level];
|
|
|
|
|
|
|
|
|
|
set_level_vks (key_state, level);
|
|
|
|
|
|
|
|
|
|
*ksymp = 0;
|
|
|
|
|
|
|
|
|
|
/* First, handle those virtual keys that we always want
|
|
|
|
|
* as special GDK_* keysyms, even if ToAsciiEx might
|
2019-08-25 12:52:24 +00:00
|
|
|
* turn some them into an ASCII character (like TAB and
|
2016-07-13 11:41:35 +00:00
|
|
|
* ESC).
|
|
|
|
|
*/
|
|
|
|
|
handle_special (vk, ksymp, level);
|
|
|
|
|
|
|
|
|
|
if ((*ksymp == 0) ||
|
|
|
|
|
((vk == VK_DECIMAL) && (level == GDK_WIN32_LEVEL_NONE)))
|
|
|
|
|
{
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
wchar_t wcs[10];
|
2020-07-24 13:54:49 +00:00
|
|
|
int k;
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
guint keysym;
|
|
|
|
|
GdkWin32KeyNode dead_key;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
wcs[0] = wcs[1] = 0;
|
|
|
|
|
k = ToUnicodeEx (vk, scancode, key_state,
|
|
|
|
|
wcs, G_N_ELEMENTS (wcs),
|
|
|
|
|
0, hkls[group]);
|
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
|
2016-07-13 11:41:35 +00:00
|
|
|
g_print ("ToUnicodeEx(%#02x, %d: %d): %d, %04x %04x\n",
|
|
|
|
|
vk, scancode, level, 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
|
2016-07-13 11:41:35 +00:00
|
|
|
switch (k)
|
|
|
|
|
{
|
|
|
|
|
case 1:
|
|
|
|
|
if ((vk == VK_DECIMAL) && (level == GDK_WIN32_LEVEL_NONE))
|
|
|
|
|
options->decimal_mark = wcs[0];
|
|
|
|
|
else
|
|
|
|
|
*ksymp = gdk_unicode_to_keyval (wcs[0]);
|
|
|
|
|
break;
|
|
|
|
|
case -1:
|
|
|
|
|
keysym = gdk_unicode_to_keyval (wcs[0]);
|
|
|
|
|
|
|
|
|
|
/* 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.
|
|
|
|
|
*/
|
|
|
|
|
reset_after_dead (key_state, hkls[group]);
|
|
|
|
|
|
|
|
|
|
/* Use dead keysyms instead of "undead" ones */
|
|
|
|
|
handle_dead (keysym, ksymp);
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
|
|
|
|
|
dead_key.undead_gdk_keycode = keysym;
|
|
|
|
|
dead_key.vk = vk;
|
|
|
|
|
dead_key.level = level;
|
|
|
|
|
dead_key.gdk_keycode = *ksymp;
|
|
|
|
|
dead_key.combinations = NULL;
|
|
|
|
|
g_array_append_val (options->dead_keys, dead_key);
|
2016-07-13 11:41:35 +00:00
|
|
|
break;
|
|
|
|
|
case 0:
|
|
|
|
|
/* Seems to be necessary to "reset" the keyboard layout
|
|
|
|
|
* in this case, too. Otherwise problems on NT4.
|
|
|
|
|
*/
|
|
|
|
|
reset_after_dead (key_state, hkls[group]);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
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
|
2016-07-13 11:41:35 +00:00
|
|
|
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
|
2016-07-13 11:41:35 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (*ksymp == 0)
|
|
|
|
|
*ksymp = GDK_KEY_VoidSymbol;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
key_state[vk] = 0;
|
|
|
|
|
|
|
|
|
|
/* Check if keyboard has an AltGr key by checking if
|
|
|
|
|
* the mapping with Control+Alt is different.
|
2017-01-04 04:31:53 +00:00
|
|
|
* Don't test CapsLock here, as it does not seem to affect
|
|
|
|
|
* dead keys themselves, only the results of dead key combinations.
|
2016-07-13 11:41:35 +00:00
|
|
|
*/
|
|
|
|
|
if (!options->has_altgr)
|
|
|
|
|
if ((keygroup[GDK_WIN32_LEVEL_ALTGR] != GDK_KEY_VoidSymbol &&
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_NONE] != keygroup[GDK_WIN32_LEVEL_ALTGR]) ||
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR] != GDK_KEY_VoidSymbol &&
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_SHIFT] != keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR]))
|
|
|
|
|
options->has_altgr = TRUE;
|
|
|
|
|
}
|
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
|
|
|
}
|
2016-07-13 11:41:35 +00:00
|
|
|
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
scancode = 0x0;
|
|
|
|
|
|
|
|
|
|
for (group = 0; group < hkls_len; group++)
|
|
|
|
|
{
|
|
|
|
|
options = &g_array_index (keymap->options, GdkWin32KeyGroupOptions, group);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < options->dead_keys->len; i++)
|
|
|
|
|
{
|
|
|
|
|
wchar_t wcs[10];
|
2020-07-24 13:54:49 +00:00
|
|
|
int k;
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
GdkWin32KeyNode *dead_key;
|
|
|
|
|
GdkWin32KeyNode combo;
|
|
|
|
|
|
|
|
|
|
dead_key = &g_array_index (options->dead_keys, GdkWin32KeyNode, i);
|
|
|
|
|
|
|
|
|
|
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
|
|
|
|
|
{
|
|
|
|
|
for (level = GDK_WIN32_LEVEL_NONE; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
{
|
|
|
|
|
/* Prime the ToUnicodeEx() internal state */
|
|
|
|
|
wcs[0] = wcs[1] = 0;
|
|
|
|
|
set_level_vks (key_state, dead_key->level);
|
|
|
|
|
k = ToUnicodeEx (dead_key->vk, scancode, key_state,
|
|
|
|
|
wcs, G_N_ELEMENTS (wcs),
|
|
|
|
|
0, hkls[group]);
|
|
|
|
|
switch (k)
|
|
|
|
|
{
|
|
|
|
|
case -1:
|
|
|
|
|
/* Okay */
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* Expected a dead key, got something else */
|
|
|
|
|
reset_after_dead (key_state, hkls[group]);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check how it combines with vk */
|
|
|
|
|
wcs[0] = wcs[1] = 0;
|
|
|
|
|
set_level_vks (key_state, level);
|
|
|
|
|
k = ToUnicodeEx (vk, scancode, key_state,
|
|
|
|
|
wcs, G_N_ELEMENTS (wcs),
|
|
|
|
|
0, hkls[group]);
|
|
|
|
|
|
|
|
|
|
if (k == 0)
|
|
|
|
|
{
|
|
|
|
|
reset_after_dead (key_state, hkls[group]);
|
|
|
|
|
}
|
|
|
|
|
else if (k == -1)
|
|
|
|
|
{
|
|
|
|
|
/* Dead key chaining? TODO: support this (deeper tree?) */
|
|
|
|
|
reset_after_dead (key_state, hkls[group]);
|
|
|
|
|
}
|
|
|
|
|
else if (k == 1)
|
|
|
|
|
{
|
|
|
|
|
combo.vk = vk;
|
|
|
|
|
combo.level = level;
|
|
|
|
|
combo.gdk_keycode = gdk_unicode_to_keyval (wcs[0]);
|
|
|
|
|
combo.undead_gdk_keycode = combo.gdk_keycode;
|
|
|
|
|
combo.combinations = NULL;
|
|
|
|
|
|
|
|
|
|
if (dead_key->combinations == NULL)
|
|
|
|
|
{
|
|
|
|
|
dead_key->combinations = g_array_new (FALSE, FALSE, sizeof (GdkWin32KeyNode));
|
|
|
|
|
g_array_set_clear_func (dead_key->combinations, (GDestroyNotify) gdk_win32_key_node_clear);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if 0
|
|
|
|
|
{
|
|
|
|
|
char *dead_key_undead_u8, *wcs_u8;
|
|
|
|
|
wchar_t t = gdk_keyval_to_unicode (dead_key->undead_gdk_keycode);
|
|
|
|
|
dead_key_undead_u8 = g_utf16_to_utf8 (&t, 1, NULL, NULL, NULL);
|
|
|
|
|
wcs_u8 = g_utf16_to_utf8 (wcs, 1, NULL, NULL, NULL);
|
2017-01-04 04:31:53 +00:00
|
|
|
g_fprintf (stdout, "%d %s%s%s0x%02x (%s) + %s%s%s0x%02x = 0x%04x (%s)\n", group,
|
|
|
|
|
(dead_key->level == GDK_WIN32_LEVEL_SHIFT ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_ALTGR ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "SHIFT-" : " ",
|
|
|
|
|
(dead_key->level == GDK_WIN32_LEVEL_CAPSLOCK ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_CAPSLOCK_ALTGR ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "CAPSLOCK-" : " ",
|
|
|
|
|
(dead_key->level == GDK_WIN32_LEVEL_ALTGR ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_ALTGR ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_CAPSLOCK_ALTGR ||
|
|
|
|
|
dead_key->level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "ALTGR-" : " ",
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
dead_key->vk,
|
|
|
|
|
dead_key_undead_u8,
|
2017-01-04 04:31:53 +00:00
|
|
|
(combo.level == GDK_WIN32_LEVEL_SHIFT ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_ALTGR ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "SHIFT-" : " ",
|
|
|
|
|
(combo.level == GDK_WIN32_LEVEL_CAPSLOCK ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_CAPSLOCK_ALTGR ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "CAPSLOCK-" : " ",
|
|
|
|
|
(combo.level == GDK_WIN32_LEVEL_ALTGR ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_ALTGR ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_CAPSLOCK_ALTGR ||
|
|
|
|
|
combo.level == GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR) ? "ALTGR-" : " ",
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
vk,
|
|
|
|
|
wcs[0],
|
|
|
|
|
wcs_u8);
|
|
|
|
|
g_free (dead_key_undead_u8);
|
|
|
|
|
g_free (wcs_u8);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
g_array_append_val (dead_key->combinations, combo);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
g_array_sort (options->dead_keys, (GCompareFunc) sort_key_nodes_by_gdk_keyval);
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
GDK_NOTE (EVENTS, print_keysym_tab (keymap));
|
|
|
|
|
|
|
|
|
|
check_that_active_layout_is_in_sync (keymap);
|
|
|
|
|
current_serial = _gdk_keymap_serial;
|
|
|
|
|
}
|
|
|
|
|
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
static gboolean
|
|
|
|
|
find_deadkey_by_keyval (GArray *dead_keys, guint16 keyval, gsize *index)
|
|
|
|
|
{
|
|
|
|
|
gsize deadkey_i;
|
|
|
|
|
gsize deadkey_i_max;
|
|
|
|
|
|
|
|
|
|
if (dead_keys->len == 0)
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
deadkey_i = 0;
|
|
|
|
|
deadkey_i_max = dead_keys->len - 1;
|
|
|
|
|
|
|
|
|
|
while (deadkey_i != deadkey_i_max)
|
|
|
|
|
{
|
|
|
|
|
GdkWin32KeyNode *dead_key;
|
|
|
|
|
gsize middle;
|
|
|
|
|
|
|
|
|
|
if (g_array_index (dead_keys, GdkWin32KeyNode, deadkey_i).gdk_keycode == keyval)
|
|
|
|
|
{
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
else if (g_array_index (dead_keys, GdkWin32KeyNode, deadkey_i_max).gdk_keycode == keyval)
|
|
|
|
|
{
|
|
|
|
|
deadkey_i = deadkey_i_max;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
else if (deadkey_i + 1 == deadkey_i_max)
|
|
|
|
|
{
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
middle = deadkey_i + (deadkey_i_max - deadkey_i) / 2;
|
|
|
|
|
dead_key = &g_array_index (dead_keys, GdkWin32KeyNode, middle);
|
|
|
|
|
|
|
|
|
|
if (dead_key->gdk_keycode < keyval)
|
|
|
|
|
deadkey_i = middle;
|
|
|
|
|
else if (dead_key->gdk_keycode > keyval)
|
|
|
|
|
deadkey_i_max = middle;
|
|
|
|
|
else
|
|
|
|
|
deadkey_i = deadkey_i_max = middle;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (g_array_index (dead_keys, GdkWin32KeyNode, deadkey_i).gdk_keycode == keyval)
|
|
|
|
|
{
|
|
|
|
|
*index = deadkey_i;
|
|
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
GdkWin32KeymapMatch
|
|
|
|
|
gdk_win32_keymap_check_compose (GdkWin32Keymap *keymap,
|
|
|
|
|
guint16 *compose_buffer,
|
|
|
|
|
gsize compose_buffer_len,
|
|
|
|
|
guint16 *output,
|
|
|
|
|
gsize *output_len)
|
|
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int partial_match;
|
W32: Prefer the deadkey combinations that the OS uses
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
2016-07-16 09:23:22 +00:00
|
|
|
guint8 active_group;
|
|
|
|
|
gsize deadkey_i, node_i;
|
|
|
|
|
GdkWin32KeyNode *dead_key;
|
|
|
|
|
GdkWin32KeyGroupOptions *options;
|
|
|
|
|
GdkWin32KeymapMatch match;
|
|
|
|
|
gsize output_size;
|
|
|
|
|
|
|
|
|
|
g_return_val_if_fail (output != NULL && output_len != NULL, GDK_WIN32_KEYMAP_MATCH_NONE);
|
|
|
|
|
|
|
|
|
|
if (compose_buffer_len < 1)
|
|
|
|
|
return GDK_WIN32_KEYMAP_MATCH_NONE;
|
|
|
|
|
|
|
|
|
|
output_size = *output_len;
|
|
|
|
|
|
|
|
|
|
active_group = _gdk_win32_keymap_get_active_group (keymap);
|
|
|
|
|
options = &g_array_index (keymap->options, GdkWin32KeyGroupOptions, active_group);
|
|
|
|
|
|
|
|
|
|
partial_match = -1;
|
|
|
|
|
match = GDK_WIN32_KEYMAP_MATCH_NONE;
|
|
|
|
|
|
|
|
|
|
if (find_deadkey_by_keyval (options->dead_keys, compose_buffer[0], &deadkey_i))
|
|
|
|
|
{
|
|
|
|
|
while (deadkey_i > 0 &&
|
|
|
|
|
g_array_index (options->dead_keys, GdkWin32KeyNode, deadkey_i - 1).gdk_keycode == compose_buffer[0])
|
|
|
|
|
deadkey_i--;
|
|
|
|
|
|
|
|
|
|
/* Hardcoded 2-tier tree here (dead key + non dead key = character).
|
|
|
|
|
* TODO: support trees with arbitrary depth for dead key chaining.
|
|
|
|
|
*/
|
|
|
|
|
dead_key = &g_array_index (options->dead_keys, GdkWin32KeyNode, deadkey_i);
|
|
|
|
|
|
|
|
|
|
/* "Partial match" means "matched the whole sequence except the last key"
|
|
|
|
|
* (right now the sequence only has 2 keys, so this turns into "matched
|
|
|
|
|
* at least the first key").
|
|
|
|
|
* "last key" should be identified by having NULL further combinations.
|
|
|
|
|
* As a heuristic, convert the buffer contents into keyvals and use
|
|
|
|
|
* them as-is (normally there should be a separate unichar buffer for
|
|
|
|
|
* each combination, but we do not store these).
|
|
|
|
|
*/
|
|
|
|
|
partial_match = deadkey_i;
|
|
|
|
|
|
|
|
|
|
if (compose_buffer_len < 2)
|
|
|
|
|
match = GDK_WIN32_KEYMAP_MATCH_INCOMPLETE;
|
|
|
|
|
|
|
|
|
|
for (node_i = 0;
|
|
|
|
|
match != GDK_WIN32_KEYMAP_MATCH_INCOMPLETE &&
|
|
|
|
|
node_i < dead_key->combinations->len;
|
|
|
|
|
node_i++)
|
|
|
|
|
{
|
|
|
|
|
GdkWin32KeyNode *node;
|
|
|
|
|
|
|
|
|
|
node = &g_array_index (dead_key->combinations, GdkWin32KeyNode, node_i);
|
|
|
|
|
|
|
|
|
|
if (keymap->keysym_tab[(node->vk * keymap->layout_handles->len + active_group) * GDK_WIN32_LEVEL_COUNT + node->level] == compose_buffer[1])
|
|
|
|
|
{
|
|
|
|
|
match = GDK_WIN32_KEYMAP_MATCH_EXACT;
|
|
|
|
|
*output_len = 0;
|
|
|
|
|
|
|
|
|
|
if (*output_len < output_size && node->gdk_keycode != 0)
|
|
|
|
|
output[(*output_len)++] = node->gdk_keycode;
|
|
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (match == GDK_WIN32_KEYMAP_MATCH_EXACT ||
|
|
|
|
|
match == GDK_WIN32_KEYMAP_MATCH_INCOMPLETE)
|
|
|
|
|
{
|
|
|
|
|
return match;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (partial_match >= 0)
|
|
|
|
|
{
|
|
|
|
|
if (compose_buffer_len == 2)
|
|
|
|
|
{
|
|
|
|
|
dead_key = &g_array_index (options->dead_keys, GdkWin32KeyNode, partial_match);
|
|
|
|
|
*output_len = 0;
|
|
|
|
|
|
|
|
|
|
if (output_size >= 1)
|
|
|
|
|
output[(*output_len)++] = dead_key->undead_gdk_keycode;
|
|
|
|
|
|
|
|
|
|
if (output_size >= 2)
|
|
|
|
|
{
|
|
|
|
|
gsize second_deadkey_i;
|
|
|
|
|
|
|
|
|
|
/* Special case for "deadkey + deadkey = space-version-of-deadkey, space-version-of-deadkey" combinations.
|
|
|
|
|
* Normally the result is a sequence of 2 unichars, but we do not store this.
|
|
|
|
|
* For "deadkey + nondeadkey = space-version-of-deadkey, nondeadkey", we can use compose_buffer
|
|
|
|
|
* contents as-is, but space version of a dead key need to be looked up separately.
|
|
|
|
|
*/
|
|
|
|
|
if (find_deadkey_by_keyval (options->dead_keys, compose_buffer[1], &second_deadkey_i))
|
|
|
|
|
output[(*output_len)++] = g_array_index (options->dead_keys, GdkWin32KeyNode, second_deadkey_i).undead_gdk_keycode;
|
|
|
|
|
else
|
|
|
|
|
output[(*output_len)++] = compose_buffer[1];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return GDK_WIN32_KEYMAP_MATCH_PARTIAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return GDK_WIN32_KEYMAP_MATCH_NONE;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
guint8
|
|
|
|
|
_gdk_win32_keymap_get_rshift_scancode (GdkWin32Keymap *keymap)
|
|
|
|
|
{
|
|
|
|
|
if (keymap != NULL &&
|
|
|
|
|
keymap->layout_handles->len > 0)
|
|
|
|
|
return g_array_index (keymap->options, GdkWin32KeyGroupOptions, keymap->active_layout).scancode_rshift;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
_gdk_win32_keymap_set_active_layout (GdkWin32Keymap *keymap,
|
|
|
|
|
HKL hkl)
|
|
|
|
|
{
|
|
|
|
|
if (keymap != NULL &&
|
|
|
|
|
keymap->layout_handles->len > 0)
|
|
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int group;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
for (group = 0; group < keymap->layout_handles->len; group++)
|
|
|
|
|
if (g_array_index (keymap->layout_handles, HKL, group) == hkl)
|
|
|
|
|
keymap->active_layout = group;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
|
_gdk_win32_keymap_has_altgr (GdkWin32Keymap *keymap)
|
|
|
|
|
{
|
|
|
|
|
if (keymap != NULL &&
|
|
|
|
|
keymap->layout_handles->len > 0)
|
|
|
|
|
return g_array_index (keymap->options, GdkWin32KeyGroupOptions, keymap->active_layout).has_altgr;
|
|
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
guint8
|
|
|
|
|
_gdk_win32_keymap_get_active_group (GdkWin32Keymap *keymap)
|
|
|
|
|
{
|
|
|
|
|
if (keymap != NULL &&
|
|
|
|
|
keymap->layout_handles->len > 0)
|
|
|
|
|
return keymap->active_layout;
|
|
|
|
|
|
|
|
|
|
return 0;
|
2015-04-29 07:31:08 +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
|
|
|
|
2001-06-22 14:08:51 +00:00
|
|
|
GdkKeymap*
|
2011-01-02 10:51:25 +00:00
|
|
|
_gdk_win32_display_get_keymap (GdkDisplay *display)
|
2001-06-22 14:08:51 +00:00
|
|
|
{
|
2002-06-20 23:59:27 +00:00
|
|
|
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
|
|
|
|
2001-06-22 14:08:51 +00:00
|
|
|
if (default_keymap == NULL)
|
2011-01-02 10:51:25 +00:00
|
|
|
default_keymap = g_object_new (gdk_win32_keymap_get_type (), NULL);
|
2001-06-22 14:08:51 +00:00
|
|
|
|
|
|
|
|
return default_keymap;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static PangoDirection
|
2016-07-13 11:41:35 +00:00
|
|
|
get_hkl_direction (HKL hkl)
|
2001-06-22 14:08:51 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
switch (PRIMARYLANGID (LOWORD ((DWORD) (gintptr) hkl)))
|
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:
|
2002-02-27 16:37:04 +00:00
|
|
|
#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:
|
2002-02-27 16:37:04 +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
|
|
|
case LANG_FARSI:
|
|
|
|
|
/* Others? */
|
|
|
|
|
return PANGO_DIRECTION_RTL;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
return PANGO_DIRECTION_LTR;
|
|
|
|
|
}
|
2001-06-22 14:08:51 +00:00
|
|
|
}
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
static PangoDirection
|
|
|
|
|
gdk_win32_keymap_get_direction (GdkKeymap *gdk_keymap)
|
|
|
|
|
{
|
|
|
|
|
HKL active_hkl;
|
|
|
|
|
GdkWin32Keymap *keymap;
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
2016-07-13 11:41:35 +00:00
|
|
|
|
2018-01-11 17:48:25 +00:00
|
|
|
if (gdk_keymap == NULL || gdk_keymap != default_keymap)
|
|
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
else
|
|
|
|
|
keymap = GDK_WIN32_KEYMAP (gdk_keymap);
|
|
|
|
|
|
|
|
|
|
update_keymap (GDK_KEYMAP (keymap));
|
|
|
|
|
|
|
|
|
|
if (keymap->layout_handles->len <= 0)
|
|
|
|
|
active_hkl = GetKeyboardLayout (0);
|
|
|
|
|
else
|
|
|
|
|
active_hkl = g_array_index (keymap->layout_handles, HKL, keymap->active_layout);
|
|
|
|
|
|
|
|
|
|
return get_hkl_direction (active_hkl);
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
2016-07-13 11:41:35 +00:00
|
|
|
gdk_win32_keymap_have_bidi_layouts (GdkKeymap *gdk_keymap)
|
2007-07-03 16:53:17 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32Keymap *keymap;
|
|
|
|
|
gboolean have_rtl = FALSE;
|
|
|
|
|
gboolean have_ltr = FALSE;
|
2020-07-24 13:54:49 +00:00
|
|
|
int group;
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
2016-07-13 11:41:35 +00:00
|
|
|
|
2018-01-11 17:48:25 +00:00
|
|
|
if (gdk_keymap == NULL || gdk_keymap != default_keymap)
|
|
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
else
|
|
|
|
|
keymap = GDK_WIN32_KEYMAP (gdk_keymap);
|
|
|
|
|
|
|
|
|
|
update_keymap (GDK_KEYMAP (keymap));
|
|
|
|
|
|
|
|
|
|
for (group = 0; group < keymap->layout_handles->len; group++)
|
|
|
|
|
{
|
|
|
|
|
if (get_hkl_direction (g_array_index (keymap->layout_handles, HKL, group)) == PANGO_DIRECTION_RTL)
|
|
|
|
|
have_rtl = TRUE;
|
|
|
|
|
else
|
|
|
|
|
have_ltr = TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return have_ltr && have_rtl;
|
2007-07-03 16:53:17 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
|
|
|
|
gdk_win32_keymap_get_caps_lock_state (GdkKeymap *keymap)
|
2008-10-01 11:02:22 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
(void) keymap;
|
|
|
|
|
|
2008-10-01 11:02:22 +00:00
|
|
|
return ((GetKeyState (VK_CAPITAL) & 1) != 0);
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
|
|
|
|
gdk_win32_keymap_get_num_lock_state (GdkKeymap *keymap)
|
2010-07-01 22:45:06 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
(void) keymap;
|
|
|
|
|
|
2010-07-01 22:45:06 +00:00
|
|
|
return ((GetKeyState (VK_NUMLOCK) & 1) != 0);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-14 11:25:38 +00:00
|
|
|
static gboolean
|
|
|
|
|
gdk_win32_keymap_get_scroll_lock_state (GdkKeymap *keymap)
|
|
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
(void) keymap;
|
|
|
|
|
|
2015-04-14 11:25:38 +00:00
|
|
|
return ((GetKeyState (VK_SCROLL) & 1) != 0);
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
2016-07-13 11:41:35 +00:00
|
|
|
gdk_win32_keymap_get_entries_for_keyval (GdkKeymap *gdk_keymap,
|
|
|
|
|
guint keyval,
|
2020-04-30 04:33:06 +00:00
|
|
|
GArray *retval)
|
2000-12-14 23:14:18 +00:00
|
|
|
{
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
2020-04-30 04:33:06 +00:00
|
|
|
guint len = retval->len;
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_return_val_if_fail (gdk_keymap == NULL || GDK_IS_KEYMAP (gdk_keymap), FALSE);
|
2000-12-14 23:14:18 +00:00
|
|
|
g_return_val_if_fail (keyval != 0, FALSE);
|
2015-04-29 07:31:08 +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
|
|
|
/* Accept only the default keymap */
|
2018-01-11 17:48:25 +00:00
|
|
|
if (gdk_keymap == NULL || gdk_keymap == default_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
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int vk;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32Keymap *keymap;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (gdk_keymap == NULL)
|
2018-01-11 17:48:25 +00:00
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
else
|
|
|
|
|
keymap = GDK_WIN32_KEYMAP (gdk_keymap);
|
|
|
|
|
|
|
|
|
|
update_keymap (gdk_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
|
|
|
|
2014-08-13 18:43:51 +00:00
|
|
|
for (vk = 0; vk < KEY_STATE_SIZE; vk++)
|
2016-07-13 11:41:35 +00:00
|
|
|
{
|
2020-07-24 13:54:49 +00:00
|
|
|
int group;
|
2016-07-13 11:41:35 +00:00
|
|
|
|
|
|
|
|
for (group = 0; group < keymap->layout_handles->len; group++)
|
|
|
|
|
{
|
|
|
|
|
GdkWin32KeyLevelState level;
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
for (level = GDK_WIN32_LEVEL_NONE; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
{
|
|
|
|
|
guint *keygroup;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
keygroup = &keymap->keysym_tab[(vk * keymap->layout_handles->len + group) * GDK_WIN32_LEVEL_COUNT];
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (keygroup[level] == keyval)
|
|
|
|
|
{
|
|
|
|
|
GdkKeymapKey key;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
key.keycode = vk;
|
|
|
|
|
key.group = group;
|
|
|
|
|
key.level = level;
|
|
|
|
|
g_array_append_val (retval, 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
|
|
|
}
|
2000-12-14 23:14:18 +00:00
|
|
|
|
Remove the event_mask, it is now in GdkWindowObject.
2002-03-01 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkwindow-win32.h (struct _GdkWindowImplWin32): Remove
the event_mask, it is now in GdkWindowObject.
* gdk/win32/gdkwindow-win32.c: Change accordingly. Set the
GDK_STRUCTURE_MASK in gdk_window_set_events(), as it is always set
in gdk_window_new(), too. (Bug#72921)
* gdk/win32/gdkevents-win32.c: Change accordingly here, too.
(vk_from_char): New function, calculates the virtual keycode
corresponding to the char in a WM_CHAR message.
(build_keypress_event, build_keyrelease_event): Use it.
(build_keypress_event): Call ImmReleaseContext() after using the
input context. This might plug a memory or resource leak.
(build_key_event_state): Remove #if 0 code.
(gdk_event_translate): Actually, it would be preferrable to always
handle just the WM_KEYDOWN and WM_KEYUP messages, not WM_CHAR at
all, and thus drop the contorted logic with ignore_wm_char etc.
* gdk/win32/gdkkeys-win32.c: (gdk_keymap_get_entries_for_keyval):
Debugging output.
(gdk_keymap_translate_keyboard_state): Return correct value. (But
_gtk_key_hash_lookup() doesn't check the return value...)
2002-02-28 23:38:55 +00:00
|
|
|
#ifdef G_ENABLE_DEBUG
|
|
|
|
|
if (_gdk_debug_flags & GDK_DEBUG_EVENTS)
|
|
|
|
|
{
|
2015-10-16 07:22:39 +00:00
|
|
|
guint i;
|
Remove the event_mask, it is now in GdkWindowObject.
2002-03-01 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkwindow-win32.h (struct _GdkWindowImplWin32): Remove
the event_mask, it is now in GdkWindowObject.
* gdk/win32/gdkwindow-win32.c: Change accordingly. Set the
GDK_STRUCTURE_MASK in gdk_window_set_events(), as it is always set
in gdk_window_new(), too. (Bug#72921)
* gdk/win32/gdkevents-win32.c: Change accordingly here, too.
(vk_from_char): New function, calculates the virtual keycode
corresponding to the char in a WM_CHAR message.
(build_keypress_event, build_keyrelease_event): Use it.
(build_keypress_event): Call ImmReleaseContext() after using the
input context. This might plug a memory or resource leak.
(build_key_event_state): Remove #if 0 code.
(gdk_event_translate): Actually, it would be preferrable to always
handle just the WM_KEYDOWN and WM_KEYUP messages, not WM_CHAR at
all, and thus drop the contorted logic with ignore_wm_char etc.
* gdk/win32/gdkkeys-win32.c: (gdk_keymap_get_entries_for_keyval):
Debugging output.
(gdk_keymap_translate_keyboard_state): Return correct value. (But
_gtk_key_hash_lookup() doesn't check the return value...)
2002-02-28 23:38:55 +00:00
|
|
|
|
|
|
|
|
g_print ("gdk_keymap_get_entries_for_keyval: %#.04x (%s):",
|
2016-07-13 11:41:35 +00:00
|
|
|
keyval, gdk_keyval_name (keyval));
|
2020-04-30 04:33:06 +00:00
|
|
|
for (i = len; i < retval->len; i++)
|
2016-07-13 11:41:35 +00:00
|
|
|
{
|
|
|
|
|
GdkKeymapKey *entry = (GdkKeymapKey *) retval->data + i;
|
|
|
|
|
g_print (" %#.02x %d %d", entry->keycode, entry->group, entry->level);
|
|
|
|
|
}
|
Remove the event_mask, it is now in GdkWindowObject.
2002-03-01 Tor Lillqvist <tml@iki.fi>
* gdk/win32/gdkwindow-win32.h (struct _GdkWindowImplWin32): Remove
the event_mask, it is now in GdkWindowObject.
* gdk/win32/gdkwindow-win32.c: Change accordingly. Set the
GDK_STRUCTURE_MASK in gdk_window_set_events(), as it is always set
in gdk_window_new(), too. (Bug#72921)
* gdk/win32/gdkevents-win32.c: Change accordingly here, too.
(vk_from_char): New function, calculates the virtual keycode
corresponding to the char in a WM_CHAR message.
(build_keypress_event, build_keyrelease_event): Use it.
(build_keypress_event): Call ImmReleaseContext() after using the
input context. This might plug a memory or resource leak.
(build_key_event_state): Remove #if 0 code.
(gdk_event_translate): Actually, it would be preferrable to always
handle just the WM_KEYDOWN and WM_KEYUP messages, not WM_CHAR at
all, and thus drop the contorted logic with ignore_wm_char etc.
* gdk/win32/gdkkeys-win32.c: (gdk_keymap_get_entries_for_keyval):
Debugging output.
(gdk_keymap_translate_keyboard_state): Return correct value. (But
_gtk_key_hash_lookup() doesn't check the return value...)
2002-02-28 23:38:55 +00:00
|
|
|
g_print ("\n");
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-04-30 04:33:06 +00:00
|
|
|
return len < retval->len;
|
2000-12-14 23:14:18 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
2016-07-13 11:41:35 +00:00
|
|
|
gdk_win32_keymap_get_entries_for_keycode (GdkKeymap *gdk_keymap,
|
|
|
|
|
guint hardware_keycode,
|
|
|
|
|
GdkKeymapKey **keys,
|
|
|
|
|
guint **keyvals,
|
2020-07-24 13:54:49 +00:00
|
|
|
int *n_entries)
|
2000-12-14 23:14:18 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
GArray *key_array;
|
|
|
|
|
GArray *keyval_array;
|
2020-07-24 13:54:49 +00:00
|
|
|
int group;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32Keymap *keymap;
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_return_val_if_fail (gdk_keymap == NULL || GDK_IS_KEYMAP (gdk_keymap), FALSE);
|
2000-12-14 23:14:18 +00:00
|
|
|
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 ||
|
2016-07-13 11:41:35 +00:00
|
|
|
hardware_keycode >= KEY_STATE_SIZE ||
|
|
|
|
|
(keys == NULL && keyvals == NULL) ||
|
2018-01-11 17:48:25 +00:00
|
|
|
(gdk_keymap != NULL && gdk_keymap != default_keymap))
|
2000-12-14 23:14:18 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
/* Wrong keycode or NULL output arrays or wrong keymap */
|
2000-12-14 23:14:18 +00:00
|
|
|
if (keys)
|
|
|
|
|
*keys = NULL;
|
|
|
|
|
if (keyvals)
|
|
|
|
|
*keyvals = NULL;
|
|
|
|
|
|
|
|
|
|
*n_entries = 0;
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2000-12-14 23:14:18 +00:00
|
|
|
if (keys)
|
|
|
|
|
key_array = g_array_new (FALSE, FALSE, sizeof (GdkKeymapKey));
|
|
|
|
|
else
|
|
|
|
|
key_array = NULL;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2000-12-14 23:14:18 +00:00
|
|
|
if (keyvals)
|
|
|
|
|
keyval_array = g_array_new (FALSE, FALSE, sizeof (guint));
|
|
|
|
|
else
|
|
|
|
|
keyval_array = NULL;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2018-01-11 17:48:25 +00:00
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
update_keymap (GDK_KEYMAP (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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
for (group = 0; group < keymap->layout_handles->len; group++)
|
|
|
|
|
{
|
|
|
|
|
GdkWin32KeyLevelState level;
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
for (level = GDK_WIN32_LEVEL_NONE; level < GDK_WIN32_LEVEL_COUNT; level++)
|
|
|
|
|
{
|
|
|
|
|
if (key_array)
|
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
|
|
|
{
|
|
|
|
|
GdkKeymapKey key;
|
2015-04-29 07:31:08 +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
|
|
|
key.keycode = hardware_keycode;
|
2016-07-13 11:41:35 +00:00
|
|
|
key.group = group;
|
|
|
|
|
key.level = level;
|
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)
|
2016-07-13 11:41:35 +00:00
|
|
|
{
|
|
|
|
|
guint keyval = keymap->keysym_tab[(hardware_keycode * keymap->layout_handles->len + group) * GDK_WIN32_LEVEL_COUNT + level];
|
|
|
|
|
|
|
|
|
|
g_array_append_val (keyval_array, keyval);
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
}
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
*n_entries = group * GDK_WIN32_LEVEL_COUNT;
|
|
|
|
|
|
2000-12-14 23:14:18 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
if (keys)
|
|
|
|
|
*keys = NULL;
|
|
|
|
|
|
|
|
|
|
if (keyvals)
|
|
|
|
|
*keyvals = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static guint
|
2016-07-13 11:41:35 +00:00
|
|
|
gdk_win32_keymap_lookup_key (GdkKeymap *gdk_keymap,
|
|
|
|
|
const GdkKeymapKey *key)
|
2000-12-14 23:14:18 +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
|
|
|
guint sym;
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32Keymap *keymap;
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_return_val_if_fail (gdk_keymap == NULL || GDK_IS_KEYMAP (gdk_keymap), 0);
|
2000-12-14 23:14:18 +00:00
|
|
|
g_return_val_if_fail (key != NULL, 0);
|
2015-04-29 07:31:08 +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
|
|
|
/* Accept only the default keymap */
|
2018-01-11 17:48:25 +00:00
|
|
|
if (gdk_keymap != NULL && gdk_keymap != default_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
|
|
|
return 0;
|
2000-12-14 23:14:18 +00:00
|
|
|
|
2018-01-11 17:48:25 +00:00
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
update_keymap (GDK_KEYMAP (keymap));
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2014-08-13 18:43:51 +00:00
|
|
|
if (key->keycode >= KEY_STATE_SIZE ||
|
2016-07-13 11:41:35 +00:00
|
|
|
key->group < 0 || key->group >= keymap->layout_handles->len ||
|
|
|
|
|
key->level < 0 || key->level >= GDK_WIN32_LEVEL_COUNT)
|
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;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
sym = keymap->keysym_tab[(key->keycode * keymap->layout_handles->len + key->group) * GDK_WIN32_LEVEL_COUNT + key->level];
|
2015-04-29 07:31:08 +00:00
|
|
|
|
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;
|
2000-12-14 23:14:18 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
static gboolean
|
2016-07-13 11:41:35 +00:00
|
|
|
gdk_win32_keymap_translate_keyboard_state (GdkKeymap *gdk_keymap,
|
|
|
|
|
guint hardware_keycode,
|
|
|
|
|
GdkModifierType state,
|
2020-07-24 13:54:49 +00:00
|
|
|
int group,
|
2016-07-13 11:41:35 +00:00
|
|
|
guint *keyval,
|
2020-07-24 13:54:49 +00:00
|
|
|
int *effective_group,
|
|
|
|
|
int *level,
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkModifierType *consumed_modifiers)
|
2000-12-14 23:14:18 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
GdkWin32Keymap *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
|
|
|
guint tmp_keyval;
|
2016-07-13 11:41:35 +00:00
|
|
|
guint *keygroup;
|
|
|
|
|
GdkWin32KeyLevelState shift_level;
|
|
|
|
|
GdkModifierType modifiers = GDK_SHIFT_MASK | GDK_LOCK_MASK | GDK_MOD2_MASK;
|
2018-01-11 17:48:25 +00:00
|
|
|
GdkKeymap *default_keymap = gdk_display_get_keymap (gdk_display_get_default ());
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
g_return_val_if_fail (gdk_keymap == NULL || GDK_IS_KEYMAP (gdk_keymap), FALSE);
|
2015-04-29 07:31:08 +00:00
|
|
|
|
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
|
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 */
|
2018-01-11 17:48:25 +00:00
|
|
|
if (gdk_keymap != NULL && gdk_keymap != default_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
|
|
|
return FALSE;
|
|
|
|
|
|
2014-08-13 18:43:51 +00:00
|
|
|
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;
|
|
|
|
|
|
2018-01-11 17:48:25 +00:00
|
|
|
keymap = GDK_WIN32_KEYMAP (default_keymap);
|
2016-07-13 11:41:35 +00:00
|
|
|
update_keymap (GDK_KEYMAP (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
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if (group < 0 || group >= keymap->layout_handles->len)
|
|
|
|
|
return FALSE;
|
2004-04-10 08:43:36 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
keygroup = &keymap->keysym_tab[(hardware_keycode * keymap->layout_handles->len + group) * GDK_WIN32_LEVEL_COUNT];
|
2004-04-10 08:43:36 +00:00
|
|
|
|
2017-01-04 04:31:53 +00:00
|
|
|
if ((state & (GDK_SHIFT_MASK | GDK_LOCK_MASK)) == (GDK_SHIFT_MASK | GDK_LOCK_MASK))
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT_CAPSLOCK;
|
|
|
|
|
else if (state & GDK_SHIFT_MASK)
|
2016-07-13 11:41:35 +00:00
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT;
|
2017-01-04 04:31:53 +00:00
|
|
|
else if (state & GDK_LOCK_MASK)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK;
|
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
|
2016-07-13 11:41:35 +00:00
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
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
|
|
|
|
2017-01-04 04:31:53 +00:00
|
|
|
if (state & GDK_MOD2_MASK)
|
2002-03-06 00:36:08 +00:00
|
|
|
{
|
2017-01-04 04:31:53 +00:00
|
|
|
if (shift_level == GDK_WIN32_LEVEL_NONE)
|
2016-07-13 11:41:35 +00:00
|
|
|
shift_level = GDK_WIN32_LEVEL_ALTGR;
|
2017-01-04 04:31:53 +00:00
|
|
|
else if (shift_level == GDK_WIN32_LEVEL_SHIFT)
|
2016-07-13 11:41:35 +00:00
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT_ALTGR;
|
2017-01-04 04:31:53 +00:00
|
|
|
else if (shift_level == GDK_WIN32_LEVEL_CAPSLOCK)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK_ALTGR;
|
|
|
|
|
else
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR;
|
2002-03-06 00:36:08 +00:00
|
|
|
}
|
|
|
|
|
|
2017-01-04 04:31:53 +00:00
|
|
|
/* Drop altgr, capslock and shift if there are no keysymbols on
|
2016-07-13 11:41:35 +00:00
|
|
|
* the key for those.
|
|
|
|
|
*/
|
|
|
|
|
if (keygroup[shift_level] == GDK_KEY_VoidSymbol)
|
2002-03-06 00:36:08 +00:00
|
|
|
{
|
2016-07-13 11:41:35 +00:00
|
|
|
switch (shift_level)
|
|
|
|
|
{
|
|
|
|
|
case GDK_WIN32_LEVEL_NONE:
|
|
|
|
|
case GDK_WIN32_LEVEL_ALTGR:
|
2017-01-04 04:31:53 +00:00
|
|
|
case GDK_WIN32_LEVEL_SHIFT:
|
|
|
|
|
case GDK_WIN32_LEVEL_CAPSLOCK:
|
2016-07-13 11:41:35 +00:00
|
|
|
if (keygroup[GDK_WIN32_LEVEL_NONE] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
|
|
|
|
break;
|
2017-01-04 04:31:53 +00:00
|
|
|
case GDK_WIN32_LEVEL_SHIFT_CAPSLOCK:
|
|
|
|
|
if (keygroup[GDK_WIN32_LEVEL_CAPSLOCK] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_SHIFT] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_NONE] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_CAPSLOCK_ALTGR:
|
|
|
|
|
if (keygroup[GDK_WIN32_LEVEL_ALTGR] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_ALTGR;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_CAPSLOCK] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_NONE] != GDK_KEY_VoidSymbol)
|
2016-07-13 11:41:35 +00:00
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
|
|
|
|
break;
|
|
|
|
|
case GDK_WIN32_LEVEL_SHIFT_ALTGR:
|
|
|
|
|
if (keygroup[GDK_WIN32_LEVEL_ALTGR] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_ALTGR;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_SHIFT] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_NONE] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
|
|
|
|
break;
|
2017-01-04 04:31:53 +00:00
|
|
|
case GDK_WIN32_LEVEL_SHIFT_CAPSLOCK_ALTGR:
|
|
|
|
|
if (keygroup[GDK_WIN32_LEVEL_CAPSLOCK_ALTGR] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK_ALTGR;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT_ALTGR;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_ALTGR] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_ALTGR;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_SHIFT_CAPSLOCK] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT_CAPSLOCK;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_CAPSLOCK] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_CAPSLOCK;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_SHIFT] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_SHIFT;
|
|
|
|
|
else if (keygroup[GDK_WIN32_LEVEL_NONE] != GDK_KEY_VoidSymbol)
|
|
|
|
|
shift_level = GDK_WIN32_LEVEL_NONE;
|
|
|
|
|
break;
|
2016-07-13 11:41:35 +00:00
|
|
|
case GDK_WIN32_LEVEL_COUNT:
|
|
|
|
|
g_assert_not_reached ();
|
|
|
|
|
}
|
2002-03-06 00:36:08 +00:00
|
|
|
}
|
|
|
|
|
|
2017-01-04 04:31:53 +00:00
|
|
|
/* See whether the shift level actually mattered
|
2002-03-06 00:36:08 +00:00
|
|
|
* to know what to put in consumed_modifiers
|
|
|
|
|
*/
|
2016-07-13 11:41:35 +00:00
|
|
|
if ((keygroup[GDK_WIN32_LEVEL_SHIFT] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_NONE] == keygroup[GDK_WIN32_LEVEL_SHIFT]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR] == GDK_KEY_VoidSymbol ||
|
2017-01-04 04:31:53 +00:00
|
|
|
keygroup[GDK_WIN32_LEVEL_ALTGR] == keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_SHIFT_CAPSLOCK] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_CAPSLOCK] == keygroup[GDK_WIN32_LEVEL_SHIFT_CAPSLOCK]))
|
|
|
|
|
modifiers &= ~GDK_SHIFT_MASK;
|
|
|
|
|
|
|
|
|
|
if ((keygroup[GDK_WIN32_LEVEL_CAPSLOCK] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_NONE] == keygroup[GDK_WIN32_LEVEL_CAPSLOCK]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_CAPSLOCK_ALTGR] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_ALTGR] == keygroup[GDK_WIN32_LEVEL_CAPSLOCK_ALTGR]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_SHIFT_CAPSLOCK] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_SHIFT] == keygroup[GDK_WIN32_LEVEL_SHIFT_CAPSLOCK]))
|
|
|
|
|
modifiers &= ~GDK_LOCK_MASK;
|
2002-03-06 00:36:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
if ((keygroup[GDK_WIN32_LEVEL_ALTGR] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_NONE] == keygroup[GDK_WIN32_LEVEL_ALTGR]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR] == GDK_KEY_VoidSymbol ||
|
2017-01-04 04:31:53 +00:00
|
|
|
keygroup[GDK_WIN32_LEVEL_SHIFT] == keygroup[GDK_WIN32_LEVEL_SHIFT_ALTGR]) &&
|
|
|
|
|
(keygroup[GDK_WIN32_LEVEL_CAPSLOCK_ALTGR] == GDK_KEY_VoidSymbol ||
|
|
|
|
|
keygroup[GDK_WIN32_LEVEL_CAPSLOCK] == keygroup[GDK_WIN32_LEVEL_CAPSLOCK_ALTGR]))
|
2016-07-13 11:41:35 +00:00
|
|
|
modifiers &= ~GDK_MOD2_MASK;
|
2002-03-06 00:36:08 +00:00
|
|
|
|
2016-07-13 11:41:35 +00:00
|
|
|
tmp_keyval = keygroup[shift_level];
|
2002-03-06 00:36:08 +00:00
|
|
|
|
2005-01-19 22:48:30 +00:00
|
|
|
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)
|
2016-07-13 11:41:35 +00:00
|
|
|
*consumed_modifiers = modifiers;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
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
|
2005-03-16 01:38:57 +00:00
|
|
|
GDK_NOTE (EVENTS, g_print ("... group=%d level=%d cmods=%#x keyval=%s\n",
|
2016-07-13 11:41:35 +00:00
|
|
|
group, shift_level, 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
|
2002-03-06 00:36:08 +00:00
|
|
|
|
2010-09-09 11:35:20 +00:00
|
|
|
return tmp_keyval != GDK_KEY_VoidSymbol;
|
2000-12-14 23:14:18 +00:00
|
|
|
}
|
2009-12-21 20:42:55 +00:00
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
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;
|
2015-04-14 11:25:38 +00:00
|
|
|
keymap_class->get_scroll_lock_state = gdk_win32_keymap_get_scroll_lock_state;
|
2011-01-02 10:51:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
