This breaks down the assumptions in stack-tracker.c and stack.c that
Mutter is only stacking X windows.
The stack tracker now tracks windows using a MetaStackWindow structure
which is a union with a type member so that X windows can be
distinguished from Wayland windows.
Some notable changes are:
Queued stack tracker operations that affect Wayland windows will not be
associated with an X serial number.
If an operation only affects a Wayland window and there are no queued
stack tracker operations ("unvalidated predictions") then the operation
is applied immediately since there is no server involved with changing
the stacking for Wayland windows.
The stack tracker can no longer respond to X events by turning them into
stack operations and discarding the predicted operations made prior to
that event because operations based on X events don't know anything
about the stacking of Wayland windows.
Instead of discarding old predictions the new approach is to trust the
predictions but whenever we receive an event from the server that
affects stacking we cross-reference with the predicted stack and check
for consistency. So e.g. if we have an event that says ADD window A then
we apply the predictions (up to the serial for that event) and verify
the predicted state includes a window A. Similarly if an event says
RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
that event) and verify that window B is above C.
If we ever receive spurious stacking events (with a serial older than we
would expect) or find an inconsistency (some things aren't possible to
predict from the compositor) then we hit a re-synchronization code-path
that will query the X server for the full stacking order and then use
that stack to walk through our combined stack and force the X windows to
match the just queried stack but avoiding disrupting the relative
stacking of Wayland windows. This will be relatively expensive but
shouldn't be hit for compositor initiated restacking operations where
our predictions should be accurate.
The code in core/stack.c that deals with synchronizing the window stack
with the X server had to be updated quite heavily. In general the patch
avoids changing the fundamental approach being used but most of the code
did need some amount of re-factoring to consider what re-stacking
operations actually involve X or not and when we need to restack X
windows we sometimes need to search for a suitable X sibling to restack
relative too since the closest siblings may be Wayland windows.
Using a public method for setting the (cached) icon geometry rather
than accessing the struct members directly allows setting the icon
geometry from extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=692997
We have some code in gnome-shell that does the equivalent of:
window.get_workspace() == workspace || window.is_on_all_workspaces();
which is a bit unwieldy. We already have a method in mutter,
so use that and document it.
https://bugzilla.gnome.org/show_bug.cgi?id=691744
Add meta_window_check_alive(), which is a simple wrapper over
meta_display_ping_window(), and takes care of showing the "Application
is not responding dialog" if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
Returns the matching tiled window. This is the topmost tiled window in a
complementary tile mode that is:
- on the same monitor;
- on the same workspace;
- spanning the remaining monitor width;
- there is no 3rd window stacked between both tiled windows that's
partially visible in the common edge.
https://bugzilla.gnome.org/show_bug.cgi?id=643075
meta_window_move_resize_frame operates much like
meta_window_move_resize, but ensures the window
and its frame (if present) will fit within the
specified dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=651899
Different bits of code were using slightly different checks to test
whether a window was an attached dialog. Add a new
meta_window_is_attached_dialog(), and use that everywhere.
Also, freeze the is-attached status when the window is first shown,
rather than recomputing it each time the caller asks, since this could
cause problems if a window changes its type after it has already been
attached, etc. However, if an attached window's parent is destroyed,
or an attached window changes its transient-for, then fix things up by
destroying the old MetaWindow and creating a new one (causing
compositor unmap and map events to be fired off, allowing the display
of the window to be fixed up).
Remove some code in display.c that tried to fix existing windows if
the gconf setting changed, but which didn't actually do anything (at
least under gnome-shell). However, if 654643 was fixed then the new
behavior with this patch would be that changing the gconf setting
would affect new dialogs, but not existing ones.
https://bugzilla.gnome.org/show_bug.cgi?id=646761
get_outer_rect now returns the visible region, and a new get_input_rect
method returns the boundaries of the full frame, including the possible
invisible regions. When undecorated, both do the samething.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
An ARGB window with a frame is likely something like a transparent
terminal. It looks awful (and breaks transparency) to draw a big
opaque black shadow under the window, so clip out the region under
the terminal from the shadow we draw.
Add meta_window_get_frame_bounds() to get a cairo region for the
outer bounds of the frame of a window, and modify the frame handling
code to notice changes to the frame shape and discard a cached
region. meta_frames_apply_shapes() is refactored so we can extract
meta_frames_get_frame_bounds() from it.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
This is useful for DnD to another monitor in gnome-shell.
In addition to a normal move it corrects the saved rect for
maximized and fullscreened windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645032
The latter move method will place the window by the origin of the
enclosing window decoration/frame, while the former will place by the
origin of the inner window, itself.
(Also moved meta_window_showing_on_its_workspace comment into
gtk-doc)
https://bugzilla.gnome.org/show_bug.cgi?id=642355
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
