We never want to send pressed keys to wayland clients on enter. The
protocol says that we should send them, presumably so that clients can
trigger their own key repeat routine in case they are given focus and
a key is physically pressed.
Unfortunately this causes some clients, in particular Xwayland, to
register key events that they really shouldn't handle, e.g. on an
Alt+Tab keybinding, where Alt is released before Tab, clients would
see Tab being pressed on enter followed by a key release event for
Tab, meaning that Tab would be processed by the client when it really
shouldn't.
Since the use case for the pressed keys array on enter seems weak to
us, we'll just fake that there are no pressed keys instead which
should be spec compliant even if it might not be true.
https://bugzilla.gnome.org/show_bug.cgi?id=727178
It only contained a pointer to a wl_resource, which isn't much of
value. Just replace it with the wl_resource instead. Any future private
data should be handled by our future role system.
The actor is updated on DnD grab motion events, properly notified
when dragging finishes, and destroyed if the client/surface disappear
below its feet.
Keeping track of the surface will be necessary in case it is destroyed
during DnD, and the coordinates will be useful when figuring out the
snap back coordinates.
When grabbing with DND, we need to leave the pointer alone and
under the client's control. The code here was a bit messy before about
when it unset the window cursor -- it did it whenever there was no
current surface after repicking, which is a bit wrong, since it will
fire during a drag grab.
Move the check for this to update_cursor_surface, which is our standard
"sync" API for this, and then call update_cursor_surface after we set
the focus.
During a DND grab, pointer->focus_surface is NULL, since the wl_pointer
doesn't have any focused surface (it's in drag mode). In this case, the
drag interface has control of the focus, and when dragging into a NULL
surface, drag_grab_focus won't get called, properly detaching it from
the previous surface.
Let the interface->focus implementation do the fizzling out.
In the future, we should split out wl_pointer's implementation
(pointer->focus_surface) from the Wayland side of the generic pointer
wrapper (pointer->current) and use our event routing system to determine
or similar whether it should go to wl_pointer or wl_data_device.
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.
