Our compose table format is still limited to 16bit
values for keysyms, but what we see in key events
can be 32bit values, and we treat them as such now.
Fixes: #4149
Make gtk_check_algorithmically take a GString
for the result. This is in preparation for allowing
multi-character results here, in the future.
Update all callers.
All tables use the compact format now, and we generate
caches in that format too. Bump the cache version to 3
for this.
Replace the python script for generating the builtin table
by a small C program using the same code to generate the data
for the builtin table. This drops the restriction on only
generating a single character in the builtin sequences.
When we find a Compose file, replace the builtin
sequences with the table we found. This matches the
semantics described in Compose(5), and makes it possible
to drop unwanted sequences from the builtin table.
It is slight change of behavior for users with existing
Compose files. To match the previous behavior, you have
to add
include "%L"
to your Compose file, to keep the builtin sequences in
addition to your own.
Keep the list of composetables private to GtkIMContextSimple,
and just have an api that creates new GtkComposeTables, either
from a file or from data.
Update tests to use the new api.
Previously it was impossible to compose characters on higher levels of
some keyboard layouts as pressing the level selection key would just
exit compose mode.
Examples for affected keyboard layouts include the Latvian
apostrophe-variant "lv(apostrophe)" (latched third level), the extended
German keyboard layout "de(e1)" (latched fifth level) as well as the
multilingual Canadian keyboard layout "ca(multix)" and the German
neo-layout "de(neo)" and its descendants (shifted fifth level).
To reproduce, set a compose key and select the Latvian apostrophe layout.
Notice that you now can input [ by pressing first the ' and then the 8-key.
Then pressing <compose>'8'8 should produce ⟦, but prior to this patch it
did not.
Avoid passing through random key press or release
events while we are showing preedit. That prevents
'accidents' like typing Ctrl-. bringing up the
Emoji chooser during preedit, or hitting Ctrl-a
after the Compose key moving the 'dot' around in
vim in terminals.
Reshuffle things to allow for a limited amount of
dead key 'chaining'. We keep up to 2 dead keys in
the preedit, so you can type
<dead_acute> <dead_cedilla> <c>
to produce ḉ, while still getting ```c with
<dead_grave> <dead_grave> <dead_grave> <c>.
For sequences like ``, we want to commit the first
deadkey and then continue preedit with the second.
The alternative is to do chained deadkeys, where
entering ~~a yields ̃̀̃̃a. But we don't do that, and
I think that would be more controversial.
It turns out that we we were sometimes emitting
preedit-end multiple times, and sometimes not at
all. Same for preedit-start. To fix this up, introduce
a in_compose_sequence flag, maintain it, and use it
in the right places.
After these changes, both
C-S-u 1 2 3 Enter
Compose a e
generate the right signals:
preedit-start, preedit-changed,..., preedit-end, commit
Tweak the preedit display for Compose sequences to
be not so distracting. We only show the Compose key
when it occurs in the middle of the sequence or is
the only key so far, and use · instead of ⎄ for it.
Also, make sure to display dead keys more adequately.
Drop GTK_MAX_COMPOSE_LEN from docs. It is no longer
used by GTK at all. We leave the define in place
for now, to avoid breaking 3rd party code that might
use it.
A bunch of keysyms for dead keys have been added since this
code was last touched. Update the check to cover the full
range from dead_grave to dead_greek.
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
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.
