A big point of this demo was to show state saving. So make it use
the new session saving protocol, which can take care of the window
size and state. We still save the color on the client side.
Use it as an example of what is to be expected to make your
application windows restore-able between executions, the session
ID is preserved in a setting between runs, so that it's fed to
the GtkApplication on startup. The actual session ID used is likewise
always stored in this setting, for later runs.
The main window gets an identifier within the session, so that its
state may be restored when first mapped.
Make this application impl object handle the integration with the
private GDK/wayland API, so this is hooked up to the xdg-session-management-v1
protocol.
As a nicety, use GtkWindow::hide-on-close to determine whether a window
should be remembered, or immediately forgotten by the session after being
closed.
This API has two "phases":
- An initialization call, calling gtk_application_set_session_id() to
set a session identifier from previous runs.
- A post-initialization call, to retrieve the session identifier in
use for this session. This may be the same identifier than previously
specified, if the session could be recovered, or a brand new one if
the session is created from scratch.
The storage of this session identifier is left up to the applications,
and could be material for later GNOME session integration with
persistent save states.
Any toplevel may be referred by an ID, that will be used by the compositor
to restore window state for it. Add the glue so that the upper layers
may restore a toplevel from one of these IDs.
Add the internal API to let the upper layers define a session
ID (e.g. saved from previous runs), and retrieve the session ID
eventually used (e.g. in case the session is created from scratch).
It seems we can get spurious de-registrations, so let's avoid spamming
the logs, and also avoid crashes from applications whose maintainer
decided to turn all critical warnings into assertions.
Previously it ended on the immediate parent of the lowest level popover,
which was not good, as it very likely was some even already hidden widget, or
at least, the a11y machinery thought so.
When selecting an emoji in the recent section, there is no need
to add it to the recent section again. This avoids a sequence of
unfortunate events, where we reconstruct the entire recent section,
thereby removing the focus child, causing the focus to revert to
the entry, causing the entry to select the entire text. In the
case of Ctrl-clicking to select multiple Emoji, the effect is that
the section Emoji will replace the entire entry text, which is
suprising and unintended.
Fixes: #6336
When prepare_gl fails in the right way (or the wrong way?), we
end up creating the leader window twice, and as a side effect,
creating two instances of the "Virtual core pointer" device, which
is bad news for grabs.
Fixes: #6840
Call wl_surface_offset in end_frame to apply the offset for drag
surfaces. This matches what the GL draw context already does, and
it fixes drag surfaces jumping at the beginning of the drag.
Fixes: #6972
On GTK's official upstream CI, all Linux runners are meant to have
/dev/udmabuf available, so this should pass. On developer machines or
downstream build environments, this can't be guaranteed (not all kernel
configurations offer that device, and on those that do, an autobuilder
might not have access to it) so make it possible to skip this with
`--no-suite=needs-udmabuf`.
Any future tests that rely on /dev/udmabuf (as opposed to using it for
optional better coverage if available, like replay-node does) can be
aded to the same suite.
Signed-off-by: Simon McVittie <smcv@debian.org>
This function is used to sort a GPtrArray of "pointers" which are
actually GINT_TO_POINTER (id), so a and b are pointers to pointer-sized
quantities.
Previously it was assuming that both were int-sized quantities,
dereferencing them to get the first sizeof(int) bytes, and then
redundantly casting those bytes to int. However, on a 64-bit big-endian
platform, the first few bytes of a larger-than-int quantity are the
most significant part, in practice 0, causing an out-of-bounds array
access and a crash. This was visible in the
`gtk:css / parser variables.css` automated test.
Bug-Debian: https://bugs.debian.org/1079546
Signed-off-by: Simon McVittie <smcv@debian.org>
Previously this code assumed that if we have an int stored in a hash
table via GINT_TO_POINTER, we can retrieve the pointer value and treat
its first sizeof(int) bytes as an item to append to a GArray of int.
However, on a 64-bit big-endian system, the first sizeof(int)
bytes of the pointer will be zero, which is not a valid ID for a
GtkCssCustomPropertyPool, causing an out-of-bounds array access and
a crash. This was visible in the `gtk:css / style` automated test.
Bug-Debian: https://bugs.debian.org/1079546
Signed-off-by: Simon McVittie <smcv@debian.org>
This more closely matches the spec. This is an API break, however the
atspi backend already assumed that this was a list, and would throw
criticals whenever this relation was set. Therefore it can be assumed
that this relation was not previously in active use.
