GitLab

When a compositor grab begins, clients will stop receiving events, so any
ongoing sequence at that time must be cancelled.

https://bugzilla.gnome.org/show_bug.cgi?id=733631

This function tells the obvious on X11, and implements a similar mechanism
on wayland to determine the "pointer emulating" sequence, or one to stick
with when implementing single-touch behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=733631

The current GNOME Shell Alt-F2 restart looks very messy and also
provides no indication to the user what is going on. We need to
restart the compositor to switch in and out of stereo mode, so
add a framework for doing this more cleanly:

Additions:

 meta_restart(): restarts the compositor with a message
 MetaDisplay::show-restart-message: signal the embedding
    shell to show a message
 MetaDisplay::restart: signal the embedding shell to restart
    itself.
 meta_is_restart(): indicates whether the current instance is a
                    restart so we can suppress login animations.

A helper program meta-restart-helper holds the composite overlay
window up during the restart to avoid visual artifacts.

https://bugzilla.gnome.org/show_bug.cgi?id=733026

Now that we have two connections to the X server, the idea of a
ref-counted server grab that might be held across extended portions
of code is very dangerous since we might try to use the backend
connection while the frontend connection is grabbed.

Replace the only usage (which was local) with direct
XGrabServer/XUngrabServer usage and remove the meta_display_grab()
API.

https://bugzilla.gnome.org/show_bug.cgi?id=733068

This makes sure that we see them for Wayland clients as well, and don't
time out and crash when we're accessing an invalid window / surface.
Spotted-by: Rui Matos <tiagomatos@gmail.com>

If a window temporarily goes unresponsive, and then returns later, we
should hide the kill dialog that we showed to the user.

Now that we don't have to regrab to change the cursor, since it's
simply the cursor on the root window, all we have to do is update
the cursor on the screen.

Grab operations are now always taken on the backend connection, and
this breaks GTK+'s event handling.

Instead of taking a grab op, just do the handling ourselves. The
GTK+ connection will get an implicit grab, which means pointer /
keyboard events won't be sent to the rest of mutter, which is good.

It's been long enough. We can mandate support for these, at least
at build-time. The code doesn't actually compile without either
of these, so just consider that unsupported.

Surprisingly, it's completely unused across all of the codebase.

is_mouse actually checks for all combinations of moving/resizing
grab ops, which is quite confusing. Just rename it.

And use it properly in some event handling code.

The idea here is that while we take a WM-side grab, like a compositor
grab or a resizing grab, we need to remove the focus from the Wayland
client.

We make a special exception for CLICKING operations, because these
are really an internal state machine while you're pressing on a button
inside a frame, and in this case, we need to not kill the focus.

We always know it will be KEY_GRAVE + 8.

We can simply check the XKB keysym here to see if it's a modifier.

It's unused outside of this one function.

A careful analysis of mutter's codebase shows that nothing actually
passes anything but 0 to this. gnome-shell has one instance, but it's
most likely a mistake.

Remove the grab_mask field and the one place in keybindings.c that uses it.

The parameter to begin_grab_op is left in for API compatibility reasons.

Just like active_screen, the screen can always be inferred
from the MetaDisplay, so there's no point in keeping it around.

We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.

With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.

We also kill off active_screen at the same time, since it's
not necessary anymore.

A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.

This will let us kill off send_icccm_message

display.c is getting a bit crowded. Move most of the handling
out to another file, events.c.

The long-term goal is to have generic event handling here, with
backend-specific handling for the types of windows and such.

If we have a CLICKING grab op we still need to send events to xwayland
so that we get them back for gtk+ to process thus we can't steer
wayland input focus away from it.

https://bugzilla.gnome.org/show_bug.cgi?id=726123

This ensures that we send the proper leave and enter events to wayland
clients.

Particularly, this solves a bug in SSD xwayland windows where clicking
and dragging on the title bar to move the window only works on the odd
turn (unless the pointer moves away from the title bar between
tries). This happens because xwayland gets a button press but doesn't
see the release so when it gets the next button press it discards it
because its pointer button tracking logic says that the button is
already pressed. Sending the proper wayland pointer leave event fixes
it since wayland clients must forget about button state at that point.

https://bugzilla.gnome.org/show_bug.cgi?id=726123

It was never turned on for all the years it's been there.

This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).

We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.

The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.

https://bugzilla.gnome.org/show_bug.cgi?id=725588

This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).

We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.

The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.

https://bugzilla.gnome.org/show_bug.cgi?id=725588

The only events we handle as XIEvents are FocusIn/Out, Enter and
Leave.  Motion, ButtonPress/Release, KeyPress/Release are handled
through clutter instead.
Among other things, this means we don't need to fake motion compression
by peeking over gdk event queue...

This reverts commit 876f81db.

This doesn't quite work properly, and is overcomplicated.