With the removal of `gdk_seat_grab` we do not need to keep the
definitions of `GdkGrabStatus` and `GdkGrabOwnership` public.
Move those definitions to become internal only.
When we `Alt+Tab` away from a GTK application, it loses keyboard focus.
If we don't clear the modifiers, events from other devices that we
receive while unfocused will assume `Alt` is still pressed. This results
in e.g. Firefox navigating through the history instead of scrolling the
page when using the mouse wheel on it.
We don't get any information about modifiers while we are missing
keyboard focus, so assuming no modifiers are active is the best we can
do.
The shell sends us a modifier update immediately before we regain
keyboard focus, so the state shouldn't get out of sync.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2112
Win32 backend doesn't have support for inhibit shortcuts, yet it needs
support the standard set of GdkToplevel properties.
Add support for the "inhibit-list" object property to GdkToplevel on
win32.
Broadway doesn't have support for inhibit shortcuts, yet it needs to
support the standard set of GdkToplevel properties.
Add support for the "inhibit-list" object property to GdkToplevel on
Broadway.
On X11, there is no such equivalent to the inhibit shortcut protocol
found on Wayland.
To implement the inhibit_system_shortcuts API on X11, we emulate the
same behavior using grabs on the keyboard.
To avoid keeping active grabs on the keyboard that would affect other
X11 applications even when the surface isn't focused, the X11
implementation takes care of releasing the grabs as soon as the toplevel
loses focus.
With the current implementation, we use a `wl_seat` as the key for our
internal has table where we store the Wayland shortcuts inhibitors.
There is however no technical reason for this, and we could use a
GdkSeat instead, which will ease the implementation of the GdkToplevel
shortcut inhibition API.
With the removal of grabs from the public API, we need a replacement API
to let applications bypass system keyboard shortcuts.
A typical use case for this API is remote desktop or virtual machine
viewers which need to inhibit the default system keyboard shortcuts so
that the remote session or virtual host gets those instead of the local
environment.
Close: https://gitlab.gnome.org/GNOME/gtk/issues/982
GTK defines various types that are meant to be derivable only within GTK
itself, and "final" from the perspective of consumers of the GTK API.
The existing macros defined by GObject, such as G_DECLARE_FINAL_TYPE and
G_DECLARE_DERIVABLE_TYPE, lack this functionality.
While we wait for GObject to get this kind of macro, we should define
our own.
Without this, the back buffers of the wrong size
keep being used, causing flickery misdraws, as
seen when expanding the expander in the popover
in widget-factory.
surface->x/y (and various x,y arguments) should be in the parent
coordinates, so treat it as such. We also keep track of the root coords
as these are needed for popup positioning.
Also, drop the isTemp property server side and the weird initial
placement at (100, 100) in the daemon. We now fully control window
placement from the client instead. If this is not we want we should do
a serious design for that but until then lets do the simplest thing.
In firefox, onload will trigger when the image is loaded, but at
that point it may not be decoded yet so showing it will sometimers
trigger flashes. We use the new decode() feature instead which ensures
both that the image is loaded *and* decoded, thus fixing the flashes.
These fixes were done blindly, to make the ci pass,
and will need review by somebody with access to an
actual win32 system to make sure the surface subtypes
are implemented properly.
