This doesn't particularly matter, since we fall through into a default
case that does nothing right below, but this matches the other paths
and it prevents us from falling into a trap if we add other event types
below.
If we start a grab op from a keybind / menu, we'll handle the
ButtonPress and drop the grab then, never giving the window a chance
to handle what it needs to do before the grab is dropped.
This means that if you use Alt+F7 to move a window around, move it
to a side-tiling or maximization area, and then left-click, it will
just hang there in the sky.
The entire point of it was to check whether the window was on the
right screen. Since we don't handle multiple screens anymore, we
don't need to check anything anymore.
Looking at the code paths where is_mouse / is_keyboard are used,
all of them should never be run when dealing with a COMPOSITOR
grab op, since they're filtered out above or the method is just
never run during that time.
It's confusing that COMPOSITOR is in here, and requires us to
be funny with other places in code, so just take it out.
pointer->current needs to always be the surface under the pointer,
even when we have a grab. We do need to make sure we keep the focus
surface the same even when we have a grab, though, so add logic
for that.
In order to correctly fix the issue to make sure we only set the
focused surface to NULL during a grab, but not the current surface,
we need to merge update_current_surface back into repick_for_event
so we have more control over the behavior here.
... not when we do an update.
We only repick when we handle events, not when we update. Perhaps
this is a mistake.
Since update runs before handle_event, this means that when we
drop a grab, update will notice the NULL surface, since we haven't
repicked after the event, and then we'll repick the correct surface.
The end result is that you see a root cursor after a grab ends,
rather than the correct window cursor.
This doesn't fix it, since the current surface becomes NULL when
we start the grab. But it does make the code here more correct when
we fix that bug.
I was talking with other people and they became confused at the
term "double-buffered", since we were also talking about
double-buffering in general, e.g. swapping between two buffers.
Instead, we'll adapt the "pending state" nomenclature that we
already use for the field / variable names.
If we have a focused surface, we need to eat up key events, not
just if we have a non-empty focus resource list. The latter would
happen if we have a focused client but it never called get_keyboard.
The latest Xorg / Xwayland has support for -displayfd being used
in conjunction with an explicit display number. Use that to know
when the X server is ready, rather than UNIX signals, because
they're UNIX signals.
We track changes to windows fullscreen state and stacking order
to determine a monitor's in-fullscreen state, but missed the
obvious case of moving a fullscreen window between monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=728395
Commit 585fdd781c not only removed the tabpopup, but set invalid
handlers (a.k.a. NULL) for those shortcuts; add back handling of
basic handling of those shortcuts by switching instantly without any
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=728423
If we're sending out a configure event, we can't immediately move the
window; we need to instead wait to apply the new position when the
client sends a new buffer.
dx/dy should be against the regular window's rect, and need to
be ignored when we're resizing. Instead, we use gravity to anchor
the window's new rectangle when resizing.
Sophisticated clients, like those using ClutterGtk, will have more
than one focused resource per client, as both Clutter and GDK will
ask for a wl_pointer / wl_keyboard. Support this naturally using
the same "hack" as Weston: multiple resource lists, where we move
elements from one to the other.
In order to support multiple pointers for the same client, we're
going to need to kill it.
This will cause crashes for now, but will be fixed by the next
commit.
Doing this synchronously means that zenity tries to initialize GTK+.
Under Wayland, that will try to connect back to mutter as a display
server. We're waiting on zenity to exit, and zenity is waiting for
a connection response. Deadlock.
Simply assume that zenity will support all the options we feed it,
since it should be the correct version. Perhaps we should replace
our use of zenity with a simple helper binary that we know will
have all the right options if this still isn't good enough.
Our focus stealing prevention is still mostly inherited from metacity;
in particular, a (non-transient) window that is not on the current
workspace will not be given focus. This behavior made sense in the
GNOME 2 days, where workspaces were separated much more strictly.
However this is no longer the case in GNOME 3 - activating a launcher
will switch workspaces if necessary, and so will the app switcher.
There is no good reason to not do the same for other user actions
like clicking a URL or activating a search result, so allow activation
of windows on non-active workspaces if a proper timestamp is supplied,
assuming that this is a strong enough indication that we are dealing
with a legitimate user action.
https://bugzilla.gnome.org/show_bug.cgi?id=728018
Effectively we have been accepting CurrentTime timestamps for years,
but still complained about "stupid pagers" when encountering them;
just accept that we will never limit treating 0 timestamps as current
time to pagers.
https://bugzilla.gnome.org/show_bug.cgi?id=728018
The code that restacks X11 windows at the end first tracks any
old windows we know about, and then handles any windows created.
It starts when it ended, and then walks forwards and then
back looking for the first X11 window it doesn't know about.
However, when there aren't any X11 windows, it flies off the end
of the array and starts looking through random memory.
When it finds the X11 window, it then goes through and then tries
to restack the remaining windows according to how we've sorted
them.
Unfortunately, META_WINDOW_CLIENT_TYPE_X11 is 0, which is quite
common in random memory we have lying around, so we enter that
path and then just crash.
Fix the buffer overrun by adding the proper bounds check to the
search.
You can easily reproduce this by opening a menu while bloatpad
is full-screen. Why it only crashes when full-screen and not
when a standard window, I have no idea.
default_grab_focus tries to add implicit grab semantics where
focus won't take effect if there's a pointer button down. This
is not what we want for popup grabs at all, as it's perfectly
valid to want to drag on a menu while there's a button down.
