This call has everything to perform activation as specified by the
xdg_activation protocol, notably a surface to activate as opposed to
gdk_display_notify_startup_complete().
Make activation happen here, so that the surface gets activated when
its gets a startup ID assigned.
The argument to xdg_activation_token_v1_set_surface is documented to be the
surface requesting the activation, not the surface to be activated, which is
given later when calling xdg_activation_v1_activate.
(c.f. 36cee4bdbc)
Use the same logic as in gdk_wayland_app_launch_context_get_startup_notify_id,
i.e. if we have a surface with focus, set that, otherwise set NULL.
This fixes requesting urgent/focus on wlroots (compositors like Sway, etc.),
which was blocked as the surface requesting the activation didn't have focus.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
By using wl_output_release(), GDK lets the compositor to clean up the
output global more nicely.
For example, currently, most compositors remove the global and then
destroy it later after N seconds expire. With this, the compositor could
experiment with destroying the output global once all its resources are
destroyed.
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
