Add a system_bell request to gtk_shell. A client can use this to invoke
the system bell, be it aural, visual or none at all. Currently per
window visual bell support is not implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
The when surface->input_region is NULL, it should be interpreted as the
whole surface region. If not, the effective input region is the
intersection of the buffer region and the input region set by
wl_surface.set_input_region. Add
meta_wayland_surface_calculate_input_region() that does this
calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Don't unset the surface->buffer if the associated wl_buffer object is
destroyed. The MetaWaylandBuffer doesn't really only represent a
wl_buffer object, but also the data (texture) created from the given
wl_buffer. Thus, for example destroying a released SHM wl_buffer should
not destroy the MetaWaylandBuffer instance, because the texture may
still be used.
This commit also fixes a race where calc_showing would hide a window
because, at the time of calculation whether it should be showing, the
surface's buffer had been destroyed as described above.
https://bugzilla.gnome.org/show_bug.cgi?id=762716
Since a buffer can be used by multiple surfaces at once,
we need to release the buffer only after all surfaces
are finished with it. Currently we track whether or
not to release the buffer based on the accessible boolean.
This commit changes it to a counter to accomodate multiple
users.
Also, each surface needs to know whether not it is done with
the buffer, so this commit adds a buffer_used boolean to the
surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
We currently track whether or not a buffer can be released early
by looking at the copied_data boolean on the buffer. This boolean
is, practically speaking, always set to TRUE for shm buffers and is
always false otherwise.
We can just as easily check if the buffer is a shm buffer to decide
whether or not to do an early release. That's better from a
theoretical point of view since copied_data assumes a 1-to-1
relationship between surface and buffer, which may not actually hold.
This commit drops copied_data and changes the check to instead see
if the buffer is shm.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
meta_wayland_surface_toplevel_commit has a lot of logic to handle
a new buffer getting attached as part of the commit. None of
that code needs to run if there is no new buffer attached.
This commit short-circuits that case.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
commit 0165cb6974 changed
mutter to release committed shm buffers as soon as they were
uploaded to the GPU.
It also inadvertently changed mutter to prematurely
release EGL buffers (which never get copied, but get used
directly).
This commit corrects that mistake.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
When a client is ready for the compositor to read a surface's
shared memory buffer, it tells the compositor via
wl_surface_commit.
From that point forward, the baton is given to the compositor:
it knows it can read the buffer without worring about the client
making changes out from under it.
After the compositor has uploaded the pixel contents to the video
card it is supposed to release the buffer back to the client so that
the client can reuse it for future use.
At the moment, mutter only releases the buffer when a new buffer
is attached. This is problematic, since it means the client has
to have a second buffer prepared before the compositor gives the
first one back. Preparing the second buffer potentially involves
copying megabytes of pixel data, so that's suboptimal, and there's
no reason mutter couldn't release the buffer earlier.
This commit changes mutter to release a surface's buffer as soon
as it's done processing the commit request.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Since we are using the surface actor to draw the DND icon, the offset
is already accounted for by MetaSurfaceActorWayland, and passing the
surface position offset would effectively double the actual offset,
causing the icon to be misplaced.
This patch always sets the anchor offset to (0, 0) when the icon is a
Wayland surface, and lets the surface actor deal with the offsetting.
https://bugzilla.gnome.org/show_bug.cgi?id=759222
Use the xdg_shell XML file installed by wayland-protocols instead of
our own copy. This protocol has yet to go through any unstable naming,
but since we had an outdated (though wire compatible) version, some
minor changes were needed.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
If we immediately dismiss the popup, we still need to set the
surface->xdg_popup pointer field in order for the destructor to
properly clean up the state. Not doing this may cause a crash if the
xdg_popup resource that was immediately dismissed is destoryed after
wl_surface during client destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=756675
When committing a toplevel surface we might no longer have a MetaWindow
associated with it. The reason may vary but some are: a popup was
dismissed, the client attached and committed a NULL buffer to a
wl_surface with the wl_shell_surface role, the client committed a
buffer to a wl_surface which previously had an toplevel window role
which extension object was destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=755490
Make a surface roles into objects with vfuncs for things where there
before was a big switch statement. The declaration and definition
boilerplate is hidden behind C macros.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a surface doesn't have a role, the compositor will not know how, if
or when it will be painted. By adding it to the compositor frame
callback list, the compositor will respond to the client that the
surface has been drawn already which might not be true.
Instead, queue the frame callback in a list that is then processed when
the surface gets a role assigned. The compositor may then, given the
role the surface got, queue the frame callback accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Being a "XWayland window" should be considered equivalent to a role,
even though it is not part of any protocol anywhere. The commit doesn't
have any functional difference, but just makes it clear that an
wl_surface managed by XWayland have the same type of special casing as
surface roles as defined by the Wayland protocol.
As the semantics are more explicit given the role is defined, a comment
explaining why the semantics need to be how they are was added.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Use a better name, use GNOME conventions for error handling, open code the
client error reporting and send the error to the correct resource.
wl_subcompositor doesn't have a role error yet, so continue use some
other error. The only effect of this is error received in the client will
be a bit confusing, it will still be disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=754215
The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."
We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.
https://bugzilla.gnome.org/show_bug.cgi?id=739163
If we can't put up a popup because grabbing the pointer fails we
immediately dismiss the popup but the client might have made requests
already, in particular it might have commited the surface and in that
case we should ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=753237
When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.
https://bugzilla.gnome.org/show_bug.cgi?id=753222
When placing a popup and the legacy transient wl_shell_surface surfaces,
take the current scale of the window into account. This commit doesn't
fix relative positioning in case a window scale would change, but since
the use case for relative positioning is mostly popups, which would be
dismissed before the parent window would be moved, it should not be that
much of a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Make meta_wayland_surface_get_toplevel_window return the top most window
in case its a chain of popups. This is to make all popups in a chain
including the top most surface have the same scale.
The reason for this is that popups are mostly integrated part of the
user interface of its parent (such as menus). Having them in a different
scale would look awkward.
Note that this doesn't affect non-popup windows with parent-child
relationship, because such windows are typically not an integral part of
the user interface (settings window, dialogs, ..) and can typically be
moved independently. It would probably make sense to make attached modal
dialogs have the same scale as their parent windows, but modal dialogs
are currently not supported for Wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
A MetaWaylandSurface was casted into a ClutterActor, but it should have
been the MetaSurfaceActor.
Move out parent_actor and surface_actor out of the loop while at it
since they won't change when iterating.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
Keep the active position state in its original coordinate space, and
synchronize the surface actor with it when it changes and when
synchronizing the rest of the surface state, in case the surface scale
had changed.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
Whenever a MetaSurfaceActor is painted, update the list of what outputs
the surface is being drawed upon. Since we do this on paint, we
effectively avoids this whenever the surface is not drawn, for example
being minimized, on a non-active workspace, or simply outside of the
damage region of a frame.
DND icons and cursors are not affected by this patch, since they are not
drawn as MetaSurfaceActors. If a MetaSurfaceActor or a parent is cloned,
then we'll check the position of the original actor again when the clone is
drawn, which is slightly expensive, but harmless. If the MetaShapedTexture
instead is cloned, as GNOME Shell does in many cases, then these clones
will not cause duplicate position checks.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
We may access it during painting even if it has been freed. For now,
manually unset it during the MetaWaylandSurface cleanup; in the future
make MetaWaylandSurface a GObject and make the surface pointer a weak
reference.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Lets use the role when doing role specific commit actions. The
conditions effectively do that anyway, and this way we will get a
compiler warning here whenever we add a new role, as well as we avoid
having different variants of role-determination checks in different
places.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface was
a xdg_surface, it'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749716
X11 client windows now hook a X11-specific MetaWaylandDragDestFuncs
that converts these into Xdnd* messages, and an additional selection
bridge has been added to take care of XdndSelection, and the data
transfers done through it.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This will be useful in order to interact with drag dest surfaces in
its windowing-specific ways, although everything defaults to the
wayland vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
Add set_modal ond unset_modal to the gtk_surface interface. When a
surface is modal, the compositor can treat it differently from non-modal
dialogs, for example attach it to the parent window if any. There is
currently no changes to input device focus; it is up to the client to
ignore events to the parent surface that is wanted.
This bumps the gtk_shell version to 2.
https://bugzilla.gnome.org/show_bug.cgi?id=745720
When a parent of a subsurface gets it state applied (either by a
wl_surface.commit, wl_subsurface.set_desync or a recursive
wl_surface.commit on a parent surface), the pending position state
of the subsurface should be applied. If the subsurface is in effective
synchronized mode (i.e. if its in explicit synchronized mode or any of
its parent surfaces is a subsurface in explicit synchronized mode), the
cached state should also be applied at this point, including its
subsurface children, recursively.
https://bugzilla.gnome.org/show_bug.cgi?id=743617
To avoid integer overflow when scaling "infinite" regions (0, 0)
(INT32_MAX, INT32_MAX), intersect with the surface rect before scaling,
instead of intersecting with the buffer rect afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=746510
If the wl_surface resource happens to be destroyed before any other
role resource, the destructor for the latter will attempt to
access/modify random memory.
Fix this by ensuring the associated resources are destroyed on the
wl_surface destructor, this will free all associated memory and
remove the resources ahead of their imminent destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=745734
MetaWaylandFrameCallback has been added a surface field, which is then
checked when destroying the surfaces. This prevents unintended callbacks
to run after a surface has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=745163
Since the surface actor knows more about how it draws itself, instead of
pushing texture state (buffer and scale), input region and opaque region
from MetaWaylandSurface after having transformed into what the surface
actor expects, make the surface actor set its own state given what state
the Wayland surface is in.
https://bugzilla.gnome.org/show_bug.cgi?id=744933
Doing this on manage() allows the common MetaWindow initialization to
do the right thing for popups like setting skip_taskbar and
skip_pager.
In particular this avoids gnome-shell's app tracker to create a new
ShellApp instance for every popup.
https://bugzilla.gnome.org/show_bug.cgi?id=745118
If a client creates an xdg_popup given a parent that is a xdg_popup that
is not the most top one in the grab chain, send the
not_the_topmost_popup error.
Also fail a client who destroys a popup that is not the top most one.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
We'll want to expose popup logic outside of meta-wayland-pointer.c and
one day we'll also probably want to add touch support for popups, so
lets move it to its own file. There are no significant semantical
changes, only refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
The commit 97a69cee5a broke the caching of
the surface state when because the frame_callback_list target state was
overwritten after the content had been moved to it.
This commit fixes it by moving the frame list addition after the copy. We
also need to initialize the list since the plain copy put garbage in it.
https://bugzilla.gnome.org/show_bug.cgi?id=743678
The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.
This reverts commit 0364ea9140.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
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.
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.
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 assume in meta_window_wayland_move_resize that the next commit that
changes the geometry will always be for our next pending operation, so
if we have a move pending on a resize, the next commit will trigger the
move. This is, of course, fundamentally wrong.
We broke this assumption even more now that we don't fizzle out calls to
meta_window_move_resize_internal and now call it on every commit, which
means that a simple damage and then commit would complete a pending
move.
This was even broken by apps like weston-terminal, which, when clicking
on the maximize button, first redraws the terminal with the maximize
button state back on hover on press, and would only redraw when it got
the configure event with the coordinates.
To track the correct commit to apply the move for, we implement the
ack_configure request and ignore all move/resizes that happen before
that.
Right now, we actually fizzle out the entire move/resize if there's a
future pending configure we're waiting on.
The grabbing state is now checked for both pointer/touch devices
within the seat, and the grab start coordinates returned by
meta_wayland_seat_get_grab_info().
https://bugzilla.gnome.org/show_bug.cgi?id=733631
This doesn't match what Weston does. I don't know of any apps that this
fixes (we don't have any apps that even use non-zero dx/dy, I don't
think), but this is part of a cleanup for window geometry.
The last commit added support for the "appmenu" button in decorations,
but didn't actually implement it. Add a new MetaWindowMenuType parameter
to the show_window_menu () functions and use it to ask the compositor
to display the app menu when the new button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
Scale surfaces based on output scale and the buffer scale set by them.
We pick the scale factor of the monitor there are mostly on.
We only handle native i.e non xwayland / legacy clients yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
Advertise the scale factor on the output and transform pointer and damage
events as well as input and opaque regions for clients
that scale up by themselves i.e use set_buffer_scale.
We do not scale any 'legacy' apps yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
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.
Really, it is a special case. When the subsurface is synchronous,
commit changes meaning from being applied immediately to being
queued up for replay later. Handle this explicit special case
with an explicit special case in the code.
This means that in all other paths, we can unconditionally
apply the actor immediately.
Even when it doesn't have a role.
This fixes cursors not quite working right, as they're a "detached"
surface without a role since nobody called set_cursor on them yet.
Instead of using commit_attached_buffer / actor_surface_commit.
We want to kill the return values of these methods because we
really should always be calling them, even if the surface doesn't
have a role.
This is also something that we did upstream. Since we want to
introduce an explicit "xdg_transient" window type for tooltips
and popovers, and since "transient_for" is a confusing dumb
80s term lifted from the ICCCM spec, just rename it.
This was changed upstream a little while ago for C++ compatibility.
It's also the more common term for the operation: you close a window,
you don't delete one. In fact, a delete event might seem like it
would be about resource management instead.
Since we get the ClientMessage after the surface is created, there's
no good way to synchronize the two streams. In this case, what we
need to do is delay the surface commit until after we get the
ClientMessage. Ideally, we'd be using a better surface system overall
where committing the surface didn't depend on what type it is, but
oh well, this is a good short-term hack for now.
The make_toplevel / window_unmanaging interface has never made
a lot of sense to me. Replace it with set_window, which does
effectively the same thing.
It's still not perfect in the case of XWayland, but I don't think
XWayland will ever make me happy.
Previously, a sequence like this would crash a client:
=> surface.attach(buffer)
=> buffer.destroy()
The correct behavior is to wait until we release the buffer before
destroying it.
=> surface.attach(buffer)
=> surface.attach(buffer2)
<= buffer.release()
=> buffer.destroy()
The protocol upstream says that "the surface contents are undefined"
in a case like this. Personally, I think that this is broken behavior
and no client should ever do it, so I explicitly killed any client
that tried to do this.
But unfortunately, as we're all well aware, XWayland does this.
Rather than wait for XWayland to be fixed, let's just allow this.
Technically, since we always copy SHM buffers into GL textures, we
could release the buffer as soon as the Cogl texture is made.
Since we do this copy, the semantics we apply are that the texture is
"frozen" in time until another newer buffer is attached. For simple
clients that simply abort on exit and don't wait for the buffer event
anyhow, this has the added bonus that we'll get nice destroy animations.
Do to a bad mixup, the surface listener was never actually fired.
This was accidentally fixed as part of a refactoring in a27fb19,
but the surface listener was broken, and we started crashing. To
fix, just remove the surface listener, as we've mostly been testing
without it.
This is not needed since the instance is being destroyed and in fact
actively harmful when code called from other handlers disconnects us
for other reasons. In that case we might crash because the
disconnection doesn't prevent other handlers from running in the
current signal emission and thus we try to remove ourselves from an
empty list.
This changes the user data of all surface extensions resources to be
the MetaWaylandSurface instead of the MetaWaylandSurfaceExtension,
which means that we no longer need all these pesky wl_container_ofs
in implementations.
Don't set the surface actor to a new buffer if it's becoming unmapped.
This is also technically wrong since we'll send out the release event,
but oh well.
We should probably decouple MetaWaylandBuffer from the CoglTexture
at some point, so we can send out releases on-demand.
This time, to make way for MetaSurfaceActorEmpty. This also fixes
destroy effects as a side effect. It still has issues if we try
to re-assign an actor that's already toplevel (e.g. somebody
re-popping up a menu that's already being destroyed), but this
will be fixed soon.
The idea here is that MetaWindowActor will do the unparenting of
the surface actor when it itself is destroyed. To prevent bad issues
with picking, we only make the surface actor reactive when it's
toplevel.
The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:
* X11 compositor. In this case, we're a traditional X11 compositor,
not a Wayland compositor. We use XCompositeNameWindowPixmap to get
the backing pixmap for the window, and deal with the COMPOSITE
extension messiness.
In this case, meta_is_wayland_compositor() is FALSE.
* Wayland clients. In this case, we're a Wayland compositor managing
Wayland surfaces. The rendering for this is fairly straightforward,
as Cogl handles most of the complexity with EGL and SHM buffers...
Wayland clients give us the input and opaque regions through
wl_surface.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.
* XWayland clients. In this case, we're a Wayland compositor, like
above, and XWayland hands us Wayland surfaces. XWayland handles
the COMPOSITE extension messiness for us, and hands us a buffer
like any other Wayland client. We have to fetch the input and
opaque regions from the X11 window ourselves.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.
We now split the rendering logic into two subclasses, which are:
* MetaSurfaceActorX11, which handles the X11 compositor case, in that
it uses XCompositeNameWindowPixmap to get the backing pixmap, and
deal with all the COMPOSITE extension messiness.
* MetaSurfaceActorWayland, which handles the Wayland compositor case
for both native Wayland clients and XWayland clients. XWayland handles
COMPOSITE for us, and handles pushing a surface over through the
xf86-video-wayland DDX.
Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
This reverts commit 283a81eac0.
This can't be done yet, as it will crash when we try to do a destroy
effect from a plugin. The surface actor needs to outlive the surface
in this case.
Though, the unparenting happening is wrong anyway for a destroy effect.
We need to figure out a sane way of doing this unparenting only after
all effects have finished.
As resource destruction can happen in any order at shutdown, we
need to be flexible here. A client disconnecting without cleaning
up all its resources should not assert fail.
The input region was set on the shaped texture, but the shaped texture
was never picked properly, as it was never set to be reactive. Move the
pick implementation and reactivity to the MetaSurfaceActor, and update
the code everywhere else to expect a MetaSurfaceActor.
I tested this with meta_window_get_input_rect and decided to change
it at the last minute. Turns out meta_window_get_rect is unlike all
the others. Just access window->rect directly instead.
Now that we call set_custom_frame_extents, the frame rect corresponds
to the "visible window geometry" used for constrainment, while the
x/y fields in get_xdg_popup instead are relative to the surface.
Both the pointer/keyboard resource and surface resource can be destroyed
at any point in the destruction process, so we need to have destroy
listeners on both. To make the code easier to follow, rename ->focus
to ->focus_surface at the same time, and rearrange the code so that
the two of them are always grouped together.
To prevent the MetaSurfaceActor from being destroyed, we normally
unparent it before we unmanage the window. However, this doesn't
work for XWayland windows, which we unmanage when we get UnmapNotify
or DestroyNotify, not when we get the wl_surface_destroy.
To solve this, add an early hook in meta_window_unmanage that
unparents the surface actor if we have one. At the same time, clean
up the destruction code to remove old comments and assumptions about
how wl_shell behaves.
