Doing clever things with objcopy is faster and seems to be reliable on
x86_64 Linux, but also doesn't work on all toolchains and architectures:
in particular, Debian has had trouble with this on arm and mips.
In a distro build environment where we are compiling all of GTK every
time, the cost of potentially unreliable builds is higher than the cost
of using slower but more conservative GResource embedding.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5107
Signed-off-by: Simon McVittie <smcv@debian.org>
The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927
Signed-off-by: Simon McVittie <smcv@debian.org>
The filetransfer protocol says to use
application/vnd.portal.filetransfer, but I used
application/vnd.portal.files when I implemented the
protocol. Oops.
This commit dds the correct mimetype, but we still
support the old one to preserve interoperatibility
with existing flatpaks using GTK 4.6.
Fixes: #5182
Some of the X keyboard layouts use compose
sequences of length one to make individual
keys generate multiple Unicode characters.
To support this use case, change the index
part of the table format to also include
an offset for length 1. Bump the table
version to indicate this change.
Fixes: #5172
For some of the a11y states, calling gtk_accessible_reset_state
can change the type of the state value from boolean or tristate
to undefined.
Handle that, instead of throwing criticals.
Related: !4910
The code in the fontrendering demo is a bit sloppy
and assumes that we always get a single run when
appending a sequence of 4 chars and 4 spaces.
That is not in general true, such as for Emoji.
Instead of working harder to handle Emoji here,
just give up and fall back to 'a'.
Fixes: #5166
