Do this by duplicating the current code and porting it to use
X again. A better approach would involve our own event structures,
and I really don't want to do that right now. We can clean this up
later.
The grab_window might be NULL, in which case we have a full-screen
grab, but we might still in a grab. Correct the check by asking
whether we're in a grab op or not.
When unmaximizing, we changed bits of window state, then called out
to code that used the frame extents *before* we cleared old cached
extents. Clear the cache up-front as soon as we change the window
state.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
When unmaximizing, we changed bits of window state, then called out
to code that used the frame extents *before* we cleared old cached
extents. Clear the cache up-front as soon as we change the window
state.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
In the past, MetaWindowGroup was allocated the size of the screen and
painted the size of the screen because it contained the screen background,
but now we also have the "top window group" which contains only popup
windows, so the allocation doesn't properly reflect the paint bounds
of the window group. Compute the paint bounds accurately from the
children.
https://bugzilla.gnome.org/show_bug.cgi?id=719669
When _GTK_FRAME_EXTENTS changes, we need to redo constraints on
the window - this matters in particular if the toolkit removes
invisible borders when a window is maximized, since otherwise
the maximized window will be positioned as if it still has
invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
In the past, MetaWindowGroup was allocated the size of the screen and
painted the size of the screen because it contained the screen background,
but now we also have the "top window group" which contains only popup
windows, so the allocation doesn't properly reflect the paint bounds
of the window group. Compute the paint bounds accurately from the
children.
https://bugzilla.gnome.org/show_bug.cgi?id=719669
When _GTK_FRAME_EXTENTS changes, we need to redo constraints on
the window - this matters in particular if the toolkit removes
invisible borders when a window is maximized, since otherwise
the maximized window will be positioned as if it still has
invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
When we have a new client, we potentially set the focus on one of its
surfaces when we map it but the client might not have called
wl_seat.get_keyboard/pointer yet. When it finally calls
get_keyboard/pointer we must then register its resource as the
focus_resource which means that we can only return early if
focus_resource is already set.
https://bugzilla.gnome.org/show_bug.cgi?id=719725
Otherwise clutter events don't have their source actor properly set
and we aren't able to determine the MetaWindow to which a given
keybinding applies.
https://bugzilla.gnome.org/show_bug.cgi?id=719724
Since subsurfaces won't have toplevel MetaWindowActors, we need to
use MetaSurfaceActor instead. These are embedded in the MetaWindowActor,
just like MetaShapedTexture was (in fact, MetaSurfaceActor now contains
a MetaShapedTexture)
Make MetaWindowActor chain up to the generic default MetaCullable
implementation, and remove the helper methods for MetaSurfaceActor
and MetaShapedTexture.
Instead of hardcoded knowledge of certain classes in MetaWindowGroup,
create a generic interface that all actors can implement to get parts of
their regions culled out during redraw, without needing any special
knowledge of how to handle a specific actor.
The names now are a bit suspect. MetaBackgroundGroup is a simple
MetaCullable that knows how to cull children, and MetaWindowGroup is the
"toplevel" cullable that computes the initial two regions. A future
cleanup here could be to merge MetaWindowGroup / MetaBackgroundGroup so
that we only have a generic MetaSimpleCullable, and move the "toplevel"
cullability to be a MetaCullableToplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=714706
