The documentation states that GTK will load a Compose
file from ~/.config/gtk-3.0/Compose. Unfortunately,
backports changed this unintentionally to look in
the gtk-4.0 directory. Change it back.
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>.
The DnD code for X11 adds the composite overlay window (aka COW) to the
cache.
Yet the X11 requests to get and release the COW may trigger XErrors that
we ought to ignore otherwise the client will abort.
Fixes: #3715
Update our compose sequences based on the current
update xorg Compose.pre file. Beyond that, remove
some deadkey sequences that we are now handling
(better) in code.
Make this script parse gtk-compose-remove.txt for
sequences to remove from the xorg Compose file.
This will be used for removing some deadkey combinations
that we can handle better in code.
Also, make this script explicitly python2. I tried
porting it to python3, but gave up in the end.
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.
because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
(cherry picked from commit b364827a5b)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
This can happen whenever the ::activate-link handler sets different
markup on the label, causing all links to be recreated. In this case,
the GtkLabelLink* passed to emit_activate_link is garbage after the
g_signal_emit call and we shouldn't try to do anything with it.
Fixes#1498
Partially fixes issue #2191 regarding switching to another app while
hovering a stylus over a drawing tablet causes subsequent mouse
clicks in the app to be ignored. I was not able to reproduce the
other behavior described in #2191 concerning tiling a window.
56f6ac5f introduced a 20px shadow for the '.tiled decoration:backdrop'
selector. This selector is more specific than the '.ssd decoration'
selector and caused unfocused tiled SSD windows to have a shadow that
focused ones did not have. The mutter code however assumes that the size
of the decoration does not change between the states and this was
causing a crash when clicking below the titlebar in unfocused tiled SSD
windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3716
