1
0
Fork 0
Commit graph

7 commits

Author SHA1 Message Date
Jonas Ådahl
2f4a68c8c3 Clean up include macros mess
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
2018-11-06 17:17:36 +01:00
Olivier Fourdan
db866eb052 wayland: send shortcut inhibit “active” event
The shortcut inhibitor protocol states that the “active” event should be
sent every time compositor shortcuts are inhibited on behalf of the
surface.

However, mutter would send that event only if the surface is focused,
which might not be the case if focus is on a shell surface.

Send the “active” event unconditionally to match the protocol
definition.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/10
2018-02-05 09:06:49 +00:00
Olivier Fourdan
13cf19e0b6 wayland: shortcuts inhibitor requires a window
Issuing a shortcut inhibit request for a surface without a window set
will lead to a crash when trying to show the shortcut inhibitor dialog.

In such a case, it's safer to deny the request.

https://bugzilla.gnome.org/show_bug.cgi?id=792599
2018-01-18 14:08:13 +01:00
Olivier Fourdan
2bf7974076 wayland: do not leak shortcut inhibit data
We would free the shortcut inhibit data only when the client destroys
its request, which is not the case when the clients itself is
destroyed, leading to a leak of the shortcut inhibit data.

Free the data on resource destruction instead, and simply destroy the
resource on destroy request.

https://bugzilla.gnome.org/show_bug.cgi?id=787568
2017-09-14 09:32:26 +02:00
Olivier Fourdan
9c16e4e2f3 wayland: Keep the inhibit shortcut dialog
On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut
inhibitor mechanism, which in turn shows the dialog, which can take
focus away from the client window when the dialog is shown.

If the client issues an ungrab() when the keyboard focus is lost, we
would hide the dialog, causing the keyboard focus to be returned to the
client surface, which in turn would issue a new grab(), so forth and so
on, causing a continuous show/hide of the shortcut inhibitor dialog.

To avoid this issue, keep the dialog around even if the shortcut inhibit
is canceled by the client, so that the user is forced to make a choice
that we can reuse on the next request without showing the dialog again.

Instead of hiding the dialog when the shortcut inhibitor is destroyed by
the client, we simply mark the request as canceled and do not apply the
user's choice.

https://bugzilla.gnome.org/show_bug.cgi?id=787568
2017-09-14 09:32:26 +02:00
Olivier Fourdan
46cb506f8f wayland: use the inhibit shortcuts dialog
Plug the new MetaInhbitShortcutsDialog to the relevant Wayland protocol
implementation.

Also, remember the last user choice for a given surface to avoid asking
continuously the same question.

https://bugzilla.gnome.org/show_bug.cgi?id=783342
2017-08-02 11:58:55 +02:00
Olivier Fourdan
2ca0871724 wayland: add keyboard shortcuts inhibitor protocol
https://bugzilla.gnome.org/show_bug.cgi?id=783342
2017-08-02 11:58:55 +02:00