In GTK4, we are now defaulting to the OpenGL renderer with the Cairo renderer
only used as a fallback, so there is no point keeping the code paths that use
layered windows as layered windows do not work well with OpenGL nor Vulkan.
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.
This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.
Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
Have an implementation of ->request_layout() and ->compute_size() for the Win32
surface backend so that we can properly display and move and resize the
windows, as we request from the Win32 APIs.
Hxndling Aerosnap properly is mostly done except for snap_up(), which needs to
to be looked at later.
In line with what is done with the Wayland backend, enable the mapped state
independently as needed from the toplevel surface presentation, and also enable
the mapped state if necessary when presenting the popup surface.
The fact that we are using gdk-pixbuf for loading files currrently does not mean we will use it going forward.
Also, "anything gdk-pixbuf can load" does not mean anything, because what gdk-pixbuf can load is a compile-time option.
As new_from_resource() will assert() if it cannot load a resource, we must be very sure that people do not use anything but PNG and JPEG for resources and the docs were not clear on that.
When destroying a wl_surface (e.g. when a window or menu is closed), the
surface may continue to exist in the compositor slightly longer than on
the client side. In that case, the surface can still receive input
events, which need to be ignored gracefully.
In particular, this prevents segfaulting on wl_surface_get_user_data()
in that situation.
Reported in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3296
The same issue for pointers/keyboards was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=693338
and fixed with in
bfd7137ffb3625f17857a8fc099a72
In pointer_surface_update_scale(), only rescale the cursor surface when
the scale has actually changed and the cursor is on at least one output.
fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3350
Right now, this issue is not completely understood, so it might also
involve some questionable handling of cursor surface by sway/wlroots.
However, irrespective of that issue, this patch avoids unnecessary calls to the
compositor, and there should be no drawback: Whenever the pointer enters
a new output, pointer_surface_update_scale() will be called again, such
that correct scaling of the cursor is still ensured.
There is a slight difference: When the cursor leaves the last output,
previously the image was reset to scale factor 1. Now, it keeps whatever
was last. That might be more sensible than the previous behaviour,
assuming that it's likely that when the cursor enter an output again, it
has the same scaling. Alternatively, if one cares about resource usage
at this level, it might make more sense to destroy the surface than
rescaling to 1.
To support Sierra, we need to have access to pasteboard types as a
NSString. Constants are provided in later versions of macOS, but we
can emulate that with an array which is initialized on first access.
On older systems, the availability of some methods seem to be incorrect
based on Apple documentation. This works around the issue by using
the rect conversion on older systems.
On x11 toplevel layout is not created before toplevel
is presented, but GTK tries to update it on idle
which leads to a crash due to accessing property
of undefined object. Treat soon to be created layout
as a layout with default values upon creation (resizable).
These functions were not implemented when the sizing changes
landed before GTK 4 was released. This fixes an issue with non-
resizeable windows not reacting to layout changes.
Fixes#3532
