GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
The proper way to do this would be to adapt the tables
to have the right data for the platform. Since 4.0 is
a new start in many ways, lets clean this up.
Reviewing the existing settings, the only backend with
some differences in the modifier intent settings is OS X,
and we would rather have that implemented by interpreting
the existing modifiers in the appropriate way.
X11 Wayland Win32 OS X
primary ctrl ctrl ctrl mod2
mnemonic alt alt alt alt
context menu - - - ctrl
extend sel shift shift shift shift
modify sel ctrl ctrl ctrl mod2
no text alt|ctrl alt|ctrl alt|ctrl mod2|ctrl
shift group varies - - alt
GTK now uses the following modifiers:
primary ctrl
mnemonic alt
extend sel shift
modify sel ctrl
no text alt|ctrl
The context menu and shift group intents were not used
in GTK at all.
Update tests to no longer expect <Primary> to roundtrip
through the accelerator parsing and formatting code.
This code needs to be redone differently, since keymaps are no
longer going to be exposed. There should really not be this much
ifdef-ed backend-specific code here anyway. Or any, really.
Add all of the keyboard translation results in the key event,
so we can translate the keyboard state at the time the event
is created, and avoid doing state translation at match time.
We actually need to carry two sets of translation results,
since we ignore CapsLock when matching accelerators, in
gdk_event_matches().
At the same time, drop the scancode field - it is only ever
set on win32, and is basically unused in GTK.
Update all callers.
We are not loading the Compose file for individual contexts,
it just gets added to a global list. So don't pass an im context
along. This will let us move the loading out of the initialization
of individual contexts, and only do it once.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
All built-in backend modules get a priority of 0 because they are the
default ones.
GtkIMContextSimple gets a priority of G_MININT because it's the fallback
one.
This mirrors the media modules code.
Otherwise gcc complains when we use these as arguments to g_new() on
32bit architectures with:
../gtk/gtkcomposetable.c: In function ‘gtk_compose_table_list_add_array’:
/usr/include/glib-2.0/glib/gmem.h:217:10: warning: argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
__p = g_##func##_n (__n, __s); \
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:279:42: note: in expansion of macro ‘_G_NEW’
#define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0)
^~~~~~
../gtk/gtkcomposetable.c:851:22: note: in expansion of macro ‘g_new0’
gtk_compose_seqs = g_new0 (guint16, length);
^~~~~~
/usr/include/glib-2.0/glib/gmem.h:96:10: note: in a call to allocation function ‘g_malloc0_n’ declared here
gpointer g_malloc0_n (gsize n_blocks,
^~~~~~~~~~~
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
This renames the GdkWindow class and related classes (impl, backend
subclasses) to surface. Additionally it renames related types:
GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType,
GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge
This is an automatic conversion using the below commands:
git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass
git sed -f g GdkWindow GdkSurface
git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing
git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING
git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2"
git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE
git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo
git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE"
git sed -f g "broadway_window" "broadway_surface"
git sed -f g "BroadwayWindow" "BroadwaySurface"
git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE"
git sed -f g "wayland_window" "wayland_surface"
git sed -f g "WaylandWindow" "WaylandSurface"
git sed -f g "X11_WINDOW" "X11_SURFACE"
git sed -f g "x11_window" "x11_surface"
git sed -f g "X11Window" "X11Surface"
git sed -f g "WIN32_WINDOW" "WIN32_SURFACE"
git sed -f g "win32_window" "win32_surface"
git sed -f g "Win32Window" "Win32Surface"
git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE"
git sed -f g "quartz_window" "quartz_surface"
git sed -f g "QuartzWindow" "QuartzSurface"
git checkout NEWS* po-properties
Unlike what commit d01ea18dc3 says, X11 is
not a requirement for Wayland, so a Wayland-only build is possible. We
just use the same logic as other non-X11 platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=784615
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
When generating introspection data, we instantiate types without
calling gtk_init, so make sure that extension points are registered
before the type is trying to implement them.
Add an extension point called gtk-im-module, which requires
the type GtkIMContext. Simplify the loading by using GIO
infrastructure. Drop the locale filtering for now, I don't
think it is really necessary nowadays.
Convert existing platform modules to gio modules.
Sill to do: Drop the conditional build machinery.
Either always include them, or never.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
As reported in https://github.com/ibus/ibus/issues/1944,
typing u201e while holding Ctrl+Shift used to give a „
when letting go of Ctrl+Shift. This broke when we introduced
Ctrl+Shift+e to start Emoji sequences. Fix this by only
looking for Ctrl+Shift+e if we are not already in a hex
sequence.
Don't beep when modifiers are released in entries.
This was an inadvertent change that snuck in with
the emoji support.
Also, don't beep while entering an emoji name.
There is entirely too much beeping here.
This commit adds some basic support for entering emoji by name
to GtkIMContextSimple. To begin an emoji sequence, use Ctrl-Shift-e
instead of Ctrl-Shift-u that is used for hex input. Otherwise, the
behavior is the same: you can can let go of the modifier keys and
end the sequence with space or enter, or hold on to the modifier
keys and end the sequence by releasing them.
Only a limited, fixed set of names is supported at this time, see
the GtkIMContextSimple docs for a full list.
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
