When a fixed size is active (e.g. the window is maximized),
gtk_window_resize() shouldn't take immediate effect, so the request was
dropped. This made GTK unhappy if this happened, it will freeze updating
the window until it received the new size it demanded.
Handle this by being nice and emitting a dummy GDK_CONFIGURE event with
the old size where we previously ignored it. It won't resize the window
immediately, so it shouldn't have a visible effect, and the size GTK
requested is still saved away for when the window is unmaximized, but
emitting the event will make GTK receive the event it expects.
We still drop the request on the floor, e.g. if we still haven't seen
the initial configuration, just as we do when actually doing the resize.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
This is not only a GdkEventButton but can also be a GdkEventTouch.
Having this annotation wrong causes bindings code to fail whenever a
wrongly typed event comes through.
Given it does seem likely Tracker is going to miss the goal to get all
applications ported to Tracker 3, the scenario where there's applications
linking to Tracker 2.x while GTK was built with Tracker 3 support becomes
more likely.
Avoid the upcoming GType clashes if that were the case, and resort to the
good (I lie) old Tracker 2 search engine.
This device may go away, which means we have a pointer to a possibly
stale object. Keep a reference here, and let future events bring this
accounting up-to-date when the mouse pointer is next updated via other
device.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/855
When using the gdk_display_close(), the handle to the Wayland compositor was not released.
This could cause the consumption of all available handles, preventing other processes from accessing the display.
Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.
Signed-off-by: Julien Ropé <jrope@redhat.com>
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
CUPS uses resource paths in the form of "printers/printer_name"
or "classes/class_name" so it is enough to remove the "printers/"
or "classes/" prefix and use the string behind it as a name.
There was recently introduced a wrong check for the prefix.
This commit fixes it in the way it was originally intended.
