AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
f737131d27
gtk2/gdk/win32/gdkwin32keys.h

73 lines
2.9 KiB
C
Raw Normal View History

win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
/* GDK - The GIMP Drawing Kit
* Copyright (C) 2010 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
Change FSF Address
2012-02-27 13:01:10 +00:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
*/
Move single-include guards inside include guards gcc has optimizations for include guards that only work if they are outermost in the the header. https://bugzilla.gnome.org/show_bug.cgi?id=689810
2012-12-28 14:57:34 +00:00
#ifndef __GDK_WIN32_KEYS_H__
#define __GDK_WIN32_KEYS_H__
Use a single compilation symbol We use a compilation symbol in our build to allow the inclusion of specific headers while building GTK, to avoid the need to include only the global header. Each namespace has its own compilation symbol because we used to have different libraries, and strict symbol visibility between libraries; now that we have a single library, and we can use private symbols across namespaces while building GTK, we should have a single compilation symbol, and simplify the build rules.
2019-11-27 13:33:43 +00:00
#if !defined (__GDKWIN32_H_INSIDE__) && !defined (GTK_COMPILATION)
win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
#error "Only <gdk/gdkwin32.h> can be included directly."
#endif
#include <gdk/gdk.h>
gdk: Make GdkKeymap a private api We have replacement apis in GdkDevice and GdkDisplay.
2020-04-05 15:29:12 +00:00
#include "gdkkeysprivate.h"
win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
G_BEGIN_DECLS
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
/**
* GdkWin32KeymapMatch:
* @GDK_WIN32_KEYMAP_MATCH_NONE: no matches found. Output is not valid.
* @GDK_WIN32_KEYMAP_MATCH_INCOMPLETE: the sequence matches so far, but is incomplete. Output is not valid.
* @GDK_WIN32_KEYMAP_MATCH_PARTIAL: the sequence matches up to the last key,
Documentation fixes Mostly fixing up indentation of continuation lines, and other small cleanups.
2021-05-18 21:05:26 +00:00
* which does not match. Output is valid.
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_KEYMAP_MATCH_EXACT: the sequence matches exactly. Output is valid.
*
* An enumeration describing the result of a deadkey combination matching.
*/
typedef enum
{
GDK_WIN32_KEYMAP_MATCH_NONE,
GDK_WIN32_KEYMAP_MATCH_INCOMPLETE,
GDK_WIN32_KEYMAP_MATCH_PARTIAL,
GDK_WIN32_KEYMAP_MATCH_EXACT
} GdkWin32KeymapMatch;
Use a single compilation symbol We use a compilation symbol in our build to allow the inclusion of specific headers while building GTK, to avoid the need to include only the global header. Each namespace has its own compilation symbol because we used to have different libraries, and strict symbol visibility between libraries; now that we have a single library, and we can use private symbols across namespaces while building GTK, we should have a single compilation symbol, and simplify the build rules.
2019-11-27 13:33:43 +00:00
#ifdef GTK_COMPILATION
win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
typedef struct _GdkWin32Keymap GdkWin32Keymap;
#else
typedef GdkKeymap GdkWin32Keymap;
#endif
typedef struct _GdkWin32KeymapClass GdkWin32KeymapClass;
#define GDK_TYPE_WIN32_KEYMAP (gdk_win32_keymap_get_type())
#define GDK_WIN32_KEYMAP(object) (G_TYPE_CHECK_INSTANCE_CAST ((object), GDK_TYPE_WIN32_KEYMAP, GdkWin32Keymap))
#define GDK_WIN32_KEYMAP_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GDK_TYPE_WIN32_KEYMAP, GdkWin32KeymapClass))
#define GDK_IS_WIN32_KEYMAP(object) (G_TYPE_CHECK_INSTANCE_TYPE ((object), GDK_TYPE_WIN32_KEYMAP))
#define GDK_IS_WIN32_KEYMAP_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GDK_TYPE_WIN32_KEYMAP))
#define GDK_WIN32_KEYMAP_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GDK_TYPE_WIN32_KEYMAP, GdkWin32KeymapClass))
GType gdk_win32_keymap_get_type (void);
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
GdkWin32KeymapMatch gdk_win32_keymap_check_compose (GdkWin32Keymap *keymap,
guint16 *compose_buffer,
gsize compose_buffer_len,
guint16 *output,
gsize *output_len);
win32: gdk3 resurrection There are sure regressions but basic stuff seems to be working again after all the API breakage done with comments like "Win32 and Quartz need to be ported still."
2011-01-02 10:51:25 +00:00
G_END_DECLS
#endif /* __GDK_WIN32_KEYMAP_H__ */
Reference in New Issue Copy Permalink