Commit Graph

17 Commits

Author SHA1 Message Date
Adel Gadllah
a378faf495 stack-tracker: Fix unitialized variable 2014-04-20 16:02:48 +02:00
Jasper St. Pierre
cd905a34fb compositor: Kill off MetaCompScreen
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.

We still keep MetaScreen in the public compositor API for compatibility
purposes.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
8b2b65246a Assume the compositor always exists
At one point, it was supported to run mutter without a compositor,
but we don't allow that any longer. A lot of code already assumes
display->compositor exists and doesn't check for a NULL pointer,
so just kill the rest of the checks.
2014-03-18 18:25:32 -04:00
Jasper St. Pierre
0be4622e14 stack-tracker: Comment out bad warning
It triggers too often, making G_DEBUG=fatal-warnings quite useless.
Owen is going to rewrite this code sometime in the near future, so
I'm just gonna kill this warning for now.
2014-02-24 09:46:22 -05:00
Andika Triwidada
9b21346427 Changed obsolete FSF postal address into generic URL.
Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-13 11:35:47 -05:00
Giovanni Campagna
b53bf0e8c2 Fix distcheck
Missing translation files, missing dists and some -Werrors.
2013-09-03 17:00:18 +02:00
Robert Bragg
40e820f551 Add support for stacking X and Wayland windows together
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.
2013-08-10 19:13:49 -04:00
Owen W. Taylor
5ceffe86ee MetaScreen: Add tracking of whether there are fullscreen windows
Trying to track the fullscreen status outside of Mutter, as GNOME Shell
was doing previously, was very prone to errors, because Mutter has a
very tricky definition of when a window is set to be fullscreen and
*actually* acting like a fullscreen window.

 * Add meta_screen_get_monitor_in_fullscreen() and an
   ::in-fullscreen-changed signal. This allows an application to
   track when there are fullscreen windows on a monitor.

 * Do the computation of fullscreen status in a "later" function that
   runs after showing, so we properly take focus into account.

 * To get ordering of different phases right, add more values
   to MetaLaterType.

 * Add auto-minimization, similar to what was added to GNOME Shell
   earlier in this cycle - if a window is set to be fullscreen, but
   not actually fullscreen, minimize.

https://bugzilla.gnome.org/show_bug.cgi?id=649748
2013-03-18 13:05:22 -04:00
Tomeu Vizoso
e0b698d365 Fix gobs of gtk-doc warnings
https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-03-14 18:02:43 -04:00
Pavel Vasin
8a6a568aca meta_stack_tracker_free(): fix memory leak
https://bugzilla.gnome.org/show_bug.cgi?id=672640
2012-05-02 14:03:56 -04:00
Dan Winship
c84da3ce1b Move the installed includes to a subdir
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
2011-03-07 18:19:53 -05:00
Owen W. Taylor
f372fa29b2 MetaStackTracker: Avoid queueing resync for obvious no-ops
Since we can't distinguish a ConfigureEvent that indicates a raise
from a ConfigureEvent that indicates a move, we get lots of
STACK_OP_RAISE_ABOVE events for windows that are already in the
right place in the stacking order. Avoid queueing a restack in that
case.

https://bugzilla.gnome.org/show_bug.cgi?id=634771
2010-11-18 09:54:44 -05:00
Owen W. Taylor
ed9d7f18a6 Avoid confusion when _NET_WM_USER_TIME_WINDOW is in the window stack
Wine sets _NET_WM_USER_TIME_WINDOW to point to an unmapped toplevel;
this was causing much confusion because both the real window and
the unmapped window were in the window stack and mapped back to the
same MetaWindow.

Debugged by Alban Browaeys
https://bugzilla.gnome.org/show_bug.cgi?id=593887
2010-09-17 14:23:33 -04:00
Owen W. Taylor
3508c4aa87 Use "later functions" to fix priority problems with Clutter redraw
There was a problem where if, for example, a restack was triggered
out of a clutter event handler, then after Clutter processed the
events, it would proceed immmediately on to repaint the stage without
ever returning control to the GLib main loop. So even though we
had an idle handler installed with a higher priority than the
Clutter stage repainting the clutter stage repainting would happen
first and we'd get a wrong frame.

Fix this by introducing the idea of "later functions", which abstract
the idea of "doing something later" away from g_idle_add() and use
a combination of GLib idle functions and Clutter "repaint functions"
to get our callbacks triggered at the right time, even when they
are installed from a clutter event handler.

https://bugzilla.gnome.org/show_bug.cgi?id=596334

This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW
could starve stage repainting.
2009-10-02 15:50:16 -04:00
Owen W. Taylor
3aff9726eb Remove MetaCompositor virtualization
Now that we only have one compositor, there's no reason to access the
compositor functions through a vtable. Remove the MetaCompositor virtualization
and make the clutter code implement the meta_compositor_* functions
directly.

Move the checks for the compositor being NULL from the vtable wrappers
to the calling code (most of them were already there, so just a few
needed to be added)

Note: the compositor is actually hard-coded on at the moment and the plan
  is to remove the non-composited code entirely, so the checks are
  added only to keep things neat: they have no practical effect.

http://bugzilla.gnome.org/show_bug.cgi?id=581813
2009-06-30 09:34:45 -04:00
Owen W. Taylor
6314ee8780 Move compositor-stack handling to MetaStackTracker
In order to properly track the stacking order for override-redirect
windows, move meta_compositor_sync_stack() call into MetaStackTracker.
In the new location, we sync the stack as a before-redraw idle function,
rather then using the freeze-thaw facilities of MetaStack. This is
simpler, and also properly compresses multiple stack changes on
notifications received from the X server.

http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-29 23:05:11 -04:00
Owen W. Taylor
a4cd66f599 Add better tracking of real stacking order
Wedging override-redirect windows into the constraint code in stack.c
results in Mutter getting confused about the stacking order of
these windows with respect to other windows, and may also in some
cases cause Mutter to restack override-redirect windows.

core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine
  events received from the X server with local changes we have made
  to come up with the best possible idea of what the stacking order
  is at any one point in time.

core/screen.c core/screen-private.h: Create a MetaStackTracker for
  the screen.

core/display.c: Feed relevant events to MetaStackTracker

core/frame.c core/screen.c core/stack.c: When we make changes to the
  stacking order or add windows, record those changes immediatley
  in MetaStackTracker so we have the information without waiting
  for a round-trip.

include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value
  for the X request serial used to create the window.

http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-29 23:04:59 -04:00