When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
The preprocessor directives for proper OS version support are missing
their last digit, rendering the checks defunct.
Improves on https://gitlab.gnome.org/GNOME/gtk/-/issues/3592 but does
not fully fix as other issues have surfaced down the line.
... until all globals have been received.
The dependency tracking introduced in 4e9be39518 only allows to
specify required globals and processes the closures as soon as
the requirements have been met. There are, however, also optional
dependencies - most notably the primary_selection protocol.
Currently we rely on the fact that compositors like Mutter announce
it before `wl_seat`, even though the order is not specified in
the spec.
Process globals closures only after all globals have been announced,
so optional dependencies can be accommodated.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/3791
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
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.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
This is useful when clients use subsurfaces independently of GDK.
For example if a client creates a subsurface that covers a GdkWindow
entirely. If this subsurface is opaque, Wayland compositors may not
emit callbacks for the surface of the GdkWindow any more.
Adding the covering subsurface via this new API ensures the
GdkWindow will continue to update in this case.
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.
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
Intel OpenGL drivers have an issue where the results of a series of
glBlitFramebuffer() can delay updating the display, when we use GDK_GL=always,
which is manifested when attempting to enter text in text boxes.
This attempts to work around this issue by requiring a glFlush() call and a
retry to the same glBlitFramebuffer() calls to avoid delays in keystrokes when
using GDK_GL=always and when not using libANGLE OpenGL/ES emulation, when an
Intel OpenGL driver is being used.
Special thanks to Lukas K. for the analysis and coming up with a workaround,
which this patch builds upon.
Fixes issue 3487
Makes event listeners active explicitly if supported; corrects
handling for deleted surfaces preventing javascript errors in
accessing deleted objects; makes event identifiers unique for
broadwayd when executing in Chrome on Android.
Partially fixes#1493
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 then
rescaling to 1.
In gdkdevice-win32.c we are interested in knowing which window
receives mouse input at a specific location.
Only WindowFromPoint is the right API for the task, other API's
(such as (Real)ChildWindowFromPoint(Ex)) have shortcomings because
they are really designed for other purposes. For example, only
WindowFromPoint is able to look through transparent layered windows.
So even if we want to find a direct child we have to use
WindowFromPoint and then walk up the hierarchy.
Fixes: #370, #417
See: !2767
There is some bug somewhere where the geometry ends up being correct.
Mutter didn't handle this gracefully, and is to be changed to simply
respect the protocol and error out the client that sends bogus data.
Prepare for this by instead of sending bogus data, complain loudly if it
would happen dropping the invalid geometry on the floor instead of
sending it.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1527
When setting a window's background to ParentRelative on X11, the window
depths must match to avoid a BadMatch error. Query the X server for the
parent window rather that relying on the parent passed to
gtk_window_new() to prevent crashes with reparented windows.
Fixes: #3288
Remove all of the selectors. They just set the passthrough anyway so
there's not much point to maintaining them and they weren't the
complete set of possible selectors.
Additionally to gtk_primary_selection, the gtk-private predecessor,
support the upstream unstable protocol.
This allows the primary selection to work on Kwin and potentially
other compositors, as well as dropping the private version eventually.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2591
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 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.
Previously, a GDK application handled the Wintab cursors (stylus,
eraser, etc.) only during app initialization. If new cursors were
recognized by Wintab during app execution, the app would not know
about them.
This fix still handles Wintab cursors known during app initialization.
In addition, when Wintab recognizes new cursors and notifies the app
via a WT_CSRCHANGE message, the app handles the new cursors, creating
new Wintab device objects for them.
Closes#1549
This may need to be changed next year, it depends on what Apple
decides to do with version numbers going forward.
Also updated GdkOSXVersion to include Catalina and Big Sur.
