Commit Graph

26 Commits

Author SHA1 Message Date
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
Simon McVittie
c2a9ccb7e2 Let the UI layer (via the core) construct the frame mask
This essentially just moves install_corners() from the compositor, through
the core, into the UI layer where it arguably should have been anyway,
leaving behind stub functions which call through the various layers. This
removes the compositor's special knowledge of how rounded corners work,
replacing it with "ask the UI for an alpha mask".

The computation of border widths and heights changes a bit, because the
width and height used in install_corners() are the
meta_window_get_outer_rect() (which includes the visible borders but not
the invisible ones), whereas the more readily-available rectangle is the
MetaFrame.rect (which includes both). Computing the same width and height
as meta_window_get_outer_rect() involves compensating for the invisible
borders, but the UI layer is the authority on those anyway, so it seems
clearer to have it do the calculations from scratch.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2013-04-17 13:35:06 +01:00
Jasper St. Pierre
8c1b2d5eda Simplify the frame testing logic in callers to grab borders
A lot of code did something similar to:

  MetaFrameBorders borders;

  if (window->frame)
    meta_frame_calc_borders (window->frame, &borders);
  else
    meta_frame_borders_clear (&borders);

Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.

https://bugzilla.gnome.org/show_bug.cgi?id=643606
2012-03-17 06:40:54 -04:00
Jasper St. Pierre
6d0c1f08d2 frame: Make sure to offset by invisible borders when unmanaging windows
When we reparent a window to the root when we're exiting, we need to offset
the position by the invisible borders, otherwise windows will creep up and
to the left.

https://bugzilla.gnome.org/show_bug.cgi?id=660848
2011-10-17 21:53:58 -04:00
Rui Matos
9f54f1d75d frame: destroy window->frame_bounds when destroying the frame
Since window->frame_bounds is used as a cache we need to invalidate it when
destroying the frame.

https://bugzilla.gnome.org/show_bug.cgi?id=660773
2011-10-04 12:47:42 +01:00
Jasper St. Pierre
d33d113746 frame: Add "get_corner_radiuses" chain
https://bugzilla.gnome.org/show_bug.cgi?id=628195
2011-08-24 09:38:23 -04:00
Jasper St. Pierre
a1a2527c75 MetaFrameBorders: Add invisible borders
This just adds the invisible border field and populates it with data
but doesn't use it in any way.

https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-08-09 17:14:51 -04:00
Jasper St. Pierre
ce9c7a210d MetaFrameBorders: Add meta_frame_borders_clear
Just a quick little commit to help clean things up for when we add invisible
borders. Additionally, do a little housekeeping in preview-widget as well.

https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-08-09 17:14:51 -04:00
Jasper St. Pierre
e0fb83c691 Replace public MetaFrameGeometry with MetaFrameBorders
There were actually *two* MetaFrameGeometry structs: one in theme-private.h,
one in frame.h. The latter public struct was populated by a mix of (void*)
casting and int pointers, usually pulling directly from the data in the private
struct.

Remove the public struct, replace it with MetaFrameBorders and scrap all
the pointer hacks to populate it, instead relying on both structs being used
in common code.

This commit should be relatively straightforward, and it should not do any
tricky logic at all, just a sophisticated find and replace.

https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-08-09 17:14:50 -04:00
Jasper St. Pierre
183bcd6fc7 Stop shaping the frame window
In preparation for switching to handling the output shape purely by what we
paint, stop applying a shape to the frame of the window. Even when we restore
handling the output shape, this will change the behavior with respect to input;
transparent areas between the frame and the contents will stop clicks rather
than passing them through, but that is arguably at least as expected
considering how that we decorate shaped windows with a frame all around.

https://bugzilla.gnome.org/show_bug.cgi?id=644930
2011-08-09 17:14:50 -04:00
Florian Müllner
7577437167 ui-frames: Delay attaching the style to new frames
Like the setting of new frames' background is delayed until the
frame is associated with its window, delay attaching the initial
style, so that the correct style variant is picked.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-05-18 23:07:23 +02:00
Florian Müllner
37aeb5baf1 frame: Delay updating the background until the frame is ready
To determine the correct background style, the UI needs to access
some frame properties via meta_core_get(); this call will bail out
early if window->frame is unset, so delay the call until the
association is made.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-05-18 23:07:22 +02:00
Owen W. Taylor
67c3c93b8f Only shadow ARGB windows with a frame outside the frame
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
2011-04-26 15:10:02 -04:00
Alexander Larsson
9d62d13f88 Split out on_all_workspaces and on_all_workspaces_requested
Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.

on_all_workspaces means this window is visible on all workspaces.

on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.

Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 13:48:54 +01: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
Florian Müllner
ed99d12e8b theme: Add tiled_left/tiled_right frame states
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.

https://bugzilla.gnome.org/show_bug.cgi?id=637330
2011-01-05 01:49:58 +01:00
Florian Müllner
b445ee3763 Remove compatibility for GTK+-2.0
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.

https://bugzilla.gnome.org/show_bug.cgi?id=633133
2010-10-28 12:16:14 +02:00
Maxim Ermilov
66105c6e7e Optionally attach modal dialogs
Add a preference /apps/mutter/general/attach_modal_dialogs. When true, instead
of having independent titlebars, modal dialogs appear attached to the titlebar
of the parent window and are moved together with the parent window.
https://bugzilla.gnome.org/show_bug.cgi?id=612726
2010-09-11 05:36:12 +04:00
Jon Nettleton
0b8a57bcba There can be only one compositor engine
Mutter is a Clutter-based compositing manager. So, remove the code for
the XRender-based compositor, and make it mandatory to have XComposite,
XRender and Clutter.

Run-time support for non-composited operation is left for now.

* src/compositor/mutter/: Move files from this subdirectory into
  the main compositor/ directory.

* compositor/compositor-xrender.ccompositor/compositor-xrender.h:
  Remove

* include/compositor-clutter.h: Remove this stray file, it had been
  replaced with compositor-mutter.h some time back.

http://bugzilla.gnome.org/show_bug.cgi?id=581813
2009-06-30 09:34:03 -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
Jon Nettleton
51a6467968 Comprehensively rename to Mutter
Code:
All references in the code not related to themes, keybindings, or
GConf were changed from 'metacity' to 'mutter'. This includes, among other
things, strings, comments, the atoms used in the message protocol, and
the envvars used for debugging. The GConf schema file was reduced to
the 3 settings new to mutter.

The overall version was brought up to 2.27 to match current gnome.

Structure:
All files named '*metacity*' were renamed '*mutter*' with appropriate
changes in the automake system.  Files removed are
doc/creating_themes, src/themes, doc/metacity-theme.dtd,
metacity.doap.  These files will eventually end up in an external
gnome-wm-data module.

Installation location:
On the filesystem the mutter-plugindir was change from
$(libdir)/metacity/plugins/clutter to just $(libdir)/mutter/plugins.
The mutter-plugins.pc.in reflects these changes.

Note:
mutter.desktop.in and mutter-wm.desktop both continue to have
X-GNOME-WMSettingsModule=metacity set.  This allows
gnome-control-center to continue using libmetacity.so for
configuration.  This is fine since most the general keybindings and wm
settings are being read from /apps/metacity/* in gconf.
2009-06-16 14:17:10 -04:00
Owen W. Taylor
626912a9a4 Merge branch 'gnome-2-26' into master
Conflicts:
	configure.in
	src/core/schema-bindings.c
2009-04-08 16:11:12 -04:00
Thomas James Alexander Thurman
b2da6d86f3 queue resize on window undecorate
* src/core/frame.c: queue resize on window undecorate


svn path=/trunk/; revision=4114
2009-02-05 01:06:15 +00:00
Tomas Frydrych
813acae961 Rename keybindings.h to keybindings-private.h 2009-01-29 14:16:01 +00:00
Iain Holmes
f141692ca2 src/include/frame.h src/include/display.h src/include/xprops.h
2008-05-19  Iain Holmes  <iain@gnome.org>

        * src/include/frame.h
        * src/include/display.h
        * src/include/xprops.h
        * src/include/compositor.h
        * src/include/types.h
        * src/include/window.h
        * src/include/errors.h
        * src/include/screen.h: New basic public API for compositor.

        * src/compositor/*: Separate the compositor out into its own 
separate
        directory and set it up for backends. Initial XRender backend.

        * src/core/compositor.[ch]: Remove

        * src/core/frame.h
        * src/core/screen.h
        * src/core/display.h
        * src/core/window.h: Rename to -private.h so as not to clash 
with the
        new files in include

        * src/core/delete.c
        * src/core/workspace.h
        * src/core/stack.[ch]
        * src/core/keybindings.[ch]
        * src/core/errors.c
        * src/core/effects.[ch]
        * src/core/core.c
        * src/core/group.h
        * src/core/edge-resistance.[ch]
        * src/core/window-props.[ch]
        * src/core/constraints.h
        * src/core/bell.[ch]
        * src/core/iconcache.h
        * src/core/session.[ch]
        * src/core/main.c
        * src/core/place.h
        * src/core/xprops.c
        * src/ui/tabpopup.c: Use the new -private headers

        * src/core/display.c
        * src/core/frame.c
        * src/core/window.c
        * src/core/screen.c: Add the API functions required by the 
compositor

        * src/Makefile.am: Relocate the new files



svn path=/trunk/; revision=3715
2008-05-19 00:00:09 +00:00
Havoc Pennington
72b08c82b1 sort source files into these directories according to which part of the WM
2007-12-19  Havoc Pennington  <hp@redhat.com>

	* src/ui, src/core, src/include: sort source files into these
	directories according to which part of the WM they are supposed to
	be in. In an eventual plan, we should also create
	src/compositor/render, src/compositor/fallback and move some of
	the compositor stuff into that.
	
	* autogen.sh: require a newer automake, so we don't have to use
	a recursive build

	* src/ui/tabpopup.c: put in a hack to make the build temporarily
	work, want to commit the large rearrangement before fixing this
	not to include workspace.h or frame.h

	* src/core/iconcache.c (meta_read_icons): temporarily break this
	to get the build to work, want to commit the large rearrangement
	before fixing this file not to include theme.h


svn path=/trunk/; revision=3491
2007-12-19 21:17:50 +00:00