So, discussing this with Jonas and Carlos on irc, Jonas is in favor of an specific API for that but Carlos not so much:

11:48 <@garnacho> ofourdan: GdkSeat and its grabs aren't going away :)
12:01 < ofourdan> garnacho: but... 
                  https://bugzilla.gnome.org/show_bug.cgi?id=789268#c20
12:01 < bugbot> Bug 789268: Backend: Wayland, normal, gtk-bugs, 
                RESOLVED FIXED, Keyboard grab by popup window causes a 
                session-modal shortcut-inhibition dialog
12:02 <@garnacho> ofourdan: I meant gdk_device_grab with "individual 
                  device grabs"
12:04 < ofourdan> garnacho: ok, so you'd be in favour of keeping 
                  wayland shortcut inhibition hidden behind the 
                  (existing) grab API or should we move it to a 
                  specific API (possibly using grabs on platforms such 
                  as x11)?
12:12 <@garnacho> ofourdan: I'm afraid of making it a separate API call 
                  precisely because support would be spotty across 
                  backends. It feels too oddly specific to be honored 
                  properly in some (eg. no idea about win32 and quartz)
12:12 < ofourdan> yeah same here, I know nothing about any backends but 
                  x11 and wayland
12:13 <@garnacho> otoh, gdk_seat_grab already has iffy promises across 
                  backends... :)
12:13 < ofourdan> I was thinking we could make a specific API that 
                  would issue a grab when the window is focused, and 
                  release it when unfocused, so we would match the 
                  Wayland behaviour
12:13 < ofourdan> but maybe it's overkill
12:18 <@garnacho> would be a fine place to set up pointer confinement 
                  if we ever added support for that. but yeah, seems a 
                  strange wayland detail to be leaked in api
12:20 <@garnacho> ofourdan: IMHO the second chunk of the patch reviewed 
                  in that bz comment you pasted is good to get in
12:22 < ofourdan> the one affecting gdk_wayland_seat_grab() ?
12:22 < ofourdan> makes sense
13:59 < ofourdan> garnacho, probably a crazy idea, but we could make it 
                  a separate api by (ab)using the GdkSeatCapabilities, 
                  like adding a GDK_SEAT_CAPABILITY_KEYBOARD_SHORTCUTS 
                  that could be explicitly grabbed on Wayland...?
14:01 < ofourdan> (the idea being that apps remain in control instead 
                  of trying to come up with heuristics as to when issue a 
                  shortcut inhibition request)
14:08 <@garnacho> ofourdan: I prefer that to an extra api call, indeed 
                  :)
14:09 < ofourdan> really?
14:11 <@garnacho> ofourdan: well, at least the "can't make deep 
                  promises" api doesn't spread. and it would also set 
                  up a precedent to separate other grabbing patterns 
                  into semantic api, which I'm unsure about
14:16 < ofourdan> (we can even report the 
                  GDK_SEAT_CAPABILITY_KEYBOARD_SHORTCUTS in 
                  gdk_wayland_seat_get_capabilities() only when the 
                  compositor supports the shortcut inhibitor protocol, 
                  neat...)

Created attachment 366883 [details] [review]
[PATCH] gdk: Add GDK_SEAT_CAPABILITY_KEYBOARD_SHORTCUTS

Instead of trying to come up with random heuristics to the existing grab
API as to when to issue a shortcut inhibition request on Wayland, add a
new virtual capability GDK_SEAT_CAPABILITY_KEYBOARD_SHORTCUTS.

This capability is reported only on Wayland for keyboard devices when
the Wayland compositor supports the shortcut inhibitor protocol.

This way, applications can tell whether the Wayland compositor supports
the shortcut inhibitor protocol, and use it along their seat grabs when
intended.

(So this is mostly an RFC at this stage, trying to gauge the water to see if this would be acceptable)

Is it really to "leak wayland details" to provide a "inhibit shortcuts" API? It's a high level feature that on X11 is implemented by grabbing, but on non-X11 cannot. I'd rather see "GdkGrab" API to be 100% client side really in all backends. Any thing that requires more "control" would be exposed in a more per-feature kind of way (such as inhibit keyboard shortcuts API), instead of dealing with actual-intent-guessing which is what we rely on now.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/982.