Some applications, like totem, create keyboard/pointer objects from the
same client, and expect it to work. We made this work a while ago, but
due to an oversight in the code, we increment the serial on button press
for every resource that we need to send events to.
Since operations like move/resize use the grab serial of the devices to
determine whether the operation is exact, we need to make sure the same
serial goes to all devices.
Restructure the code so that all that's in the resource loop is the
sending of the event -- all the calculation that's needed happens
outside.
This fixes moving / resizing the Totem window not working sometimes.
https://bugzilla.gnome.org/show_bug.cgi?id=736840
The fix in d61dde1 regressed the position of popup windows, since the
size was 0x0 when we wanted to do a sole move. Only fizzle out in the
path where we actually *do* resize.
https://bugzilla.gnome.org/show_bug.cgi?id=736812
We only broadcast input to the focus_resource_list, so we need to make
sure it's put in the proper list on startup.
This fixes input not working for windows when they first appear.
Argh. There's always more stuff to fix with keyboard/pointer. Every
single time I think I've fixed it, more stuff pops up.
GTK+ requests get_xdg_surface before attaching a buffer, and since it
might take a long time for GTK+ to get around to attaching a buffer and
committing it, our idle for MOVE_RESIZE will kick in beforehand.
And our idle will try to resize the 0x0 window that currently exists,
constrain it to 1x1, which will send a configure event of 1x1 to the
window while it boots up, causing it to awkwardly resize to the minimum
size of the window.
Make sure that in this case, our idle doesn't cause any problems, and
that we fizzle out any idles like this.
The "proper" way to do this would be to delay the creation of the
MetaWindow until a surface is committed, but that's difficult for a
variety of reasons, and might cause unintended issues with focus.
The last_sent size is effectively what size we should send in configure
requests where the size hasn't changed. Thus, if an app commits a new
size, we need to make sure we respect it and don't reconfigure it with
a size it wasn't expecting when the state changes.
This fixes apps being sent a configure event with 0, 0 on startup,
which was confusing Clutter into displaying a 0x0 viewport.
Windows can be freed at some point after they are unmanaged - because
there is an effect in progress, because a language binding is holding
a reference. Therefore, we need to clean up the later to associate
the xwayland and wayland windows deterministically in an "unamanaged"
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later. Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
Putting X windows and pointers to MetaWindows into a union had a number of
problems:
- It caused awkward initialization and conditionalization
- There was no way to refer to Wayland windows (represented by
MetaWindow *) in the past, which is necessary for the MetaStackTracker
algorithms
- We never even cleaned up old MetaStackWindow so there could be
records in MetaStackWindow pointing to freed MetaWindow.
Replace MetaStackWindow with a 64-bit "stack ID" which is:
- The XID for X Windows
- a "window stamp" for Wayland windows - window stamps are assigned
for all MetaWindow and are unique across the life of the process.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Add private functions for the test framework to use to find out the
wayland and x11 display names, so they can set up the environment for
children.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
It's possible for a released pointer to have repick / set_focus on it as
part of sync_input_focus. When the pointer is actually re-init'd, it
will memset 0, which can cause corruption as our destroy listener has
already been added.
Released devices should be idempotent, so just make sure method calls on
them don't have any effect.
A wl_surface may have a wl_subsurface interface, but no buffers attached
yet, even though the geometry calculation code for surfaces/subsurfaces
assumes everything has already a buffer.
Just skip subsurfaces that don't have a buffer, those can't be set
a geometry yet, and right now it's crashing accessing the texture from
the NULL surface->buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=735452
This makes it so that MetaSurfaceActorWayland is effectively just a
wrapper actor around MetaShapedTexture with some extra scaling. I think
the MetaSurfaceActor subclassing was a bad idea -- we really should have
these abstractions in much higher levels in the stack than the
compositor.
It doesn't make sense to update it in the surface actor. It's also
theoretically wrong to update the buffer's texture on surface commit,
too, because it's buffer state, not surface state, but I don't think
there's any place we use a wl_buffer without a wl_surface.
The initialization sequence before was quite icky, initializing Clutter
in a few different places depending on what was going on.
Put that all back into main.c
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
We've long used a switch statement on the grab operation to determine
where events should go. The issue with MetaGrabOp is that it's a mixture
of a few different things, including event routing, state management,
and the behavior to choose during operations.
This leads to poorly defined event routing and hard-to-follow logic,
since it's sometimes unclear what should point where, and our utility
methods for determining grab operations apart can be poorly named.
To fix this, establish the concept of a "event route", which describes
where events should be routed to.
Refuse to create a touch resource if we don't have the capability
(for misbehaving clients), and don't attempt to use touch data
structures that are not initialized.
This is a terrible hack. We need to figure out a better way to do
interactive resizes.
This fixes weird resizing from the left bugs when using GTK+, which is
really slow at acking configures.
This is an easy way to get into an infinite loop where we're constantly
re-sending stuff to the window. If it worked once, it probably won't
work again.
