Commit Graph

110 Commits

Author SHA1 Message Date
Jasper St. Pierre
153d8efcf5 window: Create a backing MetaWindow for unmapped Wayland surfaces
We require a MetaWindow to properly implement some of the requests
for xdg_surface, so add a way to have an unmapped MetaWindow that
we can store properties on, that we later map when the client
attaches a buffer...
2013-11-19 17:48:19 -05:00
Jasper St. Pierre
d945501be6 window: Remove width/height from meta_window_new_for_wayland 2013-11-19 15:37:33 -05:00
Owen W. Taylor
a4a8f1f863 MetaFrame: Cache borders
Cache the computed border size so we can fetch the border size at
any time without worrying that we'll be spending too much time in
the theme code (in some cases we might allocate a PangoFontDescription
or do other significant work.)

The main effort here is clearing the cache when various bits of window
state change that could potentially affect the computed borders.

https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-19 14:04:16 -05:00
Jasper St. Pierre
23ba3e527f wayland: Support alternative focus modes like focus-follows-mouse
Use the existing code for MetaWindow focus-follows-mouse to support this.
2013-11-12 16:53:15 -05:00
Jasper St. Pierre
e86c53230f display: Move the pointer event handling code to work in terms of Clutter events
There is now a meta_display_handle_event alongside the
meta_display_handle_xevent function which handles events in terms of
Clutter events instead of X events. A Clutter event filter is
registered so that all Clutter events will pass through this function.
The pointer event handling code from the X event version has been moved
into this new function and has been modified to use the details from
the Clutter event instead of the X event. This is a step towards
moving all of the event handling code over to use Clutter events.

Based-heavily-on-a-patch-by: Neil Roberts <neil@linux.intel.com>
2013-11-12 16:53:14 -05:00
Giovanni Campagna
76e2455d1b wayland: implement support for popup surfaces
Popup surfaces are mapped into override_redirect surfaces
of a DROPDOWN_MENU type, with the addition of a special pointer
grab.

https://bugzilla.gnome.org/show_bug.cgi?id=707863
2013-09-16 14:51:12 +02:00
Giovanni Campagna
81d9797544 wayland: implement transient hints for wayland clients
wl_shell supports a set_transient() map request that is equivalent
to setting WM_TRANSIENT_FOR in X11, so implement that.

https://bugzilla.gnome.org/show_bug.cgi?id=707401
2013-09-16 14:48:57 +02:00
Giovanni Campagna
a7eaf43e18 wayland: implement resizing and maximization for wayland clients
To properly resize clients, we need to send them configure events
with the size we computed from the constraint system, and
then check if the new size they ask is compatible with
our expectation.

Note that this does not handle interactive resizing yet, it
merely makes the API calls work for wayland clients.

https://bugzilla.gnome.org/show_bug.cgi?id=707401
2013-09-16 14:46:34 +02:00
Giovanni Campagna
a26ded47d9 Add a private gtk-mutter protocol
Add a new interface, gtk_shell, than can be used by gtk to
retrieve a surface extension called gtk_surface, which will be
used to communicate with mutter all the GTK extensions to EWMH

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

Add support for GTK application menus

To do so, we need to be able to set surface state before creating
the MetaWindow, so we introduce MetaWaylandSurfaceInitialState as
a staging area.
The gtk-shell-surface implementation would either write to the
initial state, or directly to the window.

At the same, implement set_title and set_class too, because it's
easy enough.

https://bugzilla.gnome.org/show_bug.cgi?id=707128
2013-09-03 10:57:28 -04:00
Giovanni Campagna
806d5939e3 wayland: split headers and distribute structure definitions
Instead of having all structures in one huge headers, move them
in the appropriate place, and create one header for surface state.

https://bugzilla.gnome.org/show_bug.cgi?id=707128
2013-09-03 10:57:28 -04:00
Jasper St. Pierre
2d35e07fae wayland: Add support for set_opaque_region / set_input_region
https://bugzilla.gnome.org/show_bug.cgi?id=707019
2013-08-29 15:31:52 -04:00
Giovanni Campagna
aa15c09d54 Merge tag 'xrandr_branch_point' into wayland-kms-base
Conflicts:
	src/Makefile.am
	src/core/display.c
	src/core/screen-private.h
	src/core/screen.c
2013-08-27 10:07:39 +02:00
Giovanni Campagna
bd3d5df9ce Remove HAVE_WAYLAND ifdefs
Wayland support is always enabled now.

https://bugzilla.gnome.org/show_bug.cgi?id=705497
2013-08-26 15:00:29 +02:00
Giovanni Campagna
214f31257b Rework and consolidate monitor handling in MetaScreen
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-18 00:22:54 +02:00
Jasper St. Pierre
0e098249b1 Merge remote-tracking branch 'origin/master' into wayland 2013-08-13 10:44:09 -04:00
Jasper St. Pierre
12d2e1f600 Support _GTK_FRAME_EXTENTS
https://bugzilla.gnome.org/show_bug.cgi?id=705766
2013-08-13 10:40:15 -04: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
Robert Bragg
f9a11b3b18 wayland: Adds basic hybrid X + Wayland support
This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.

This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.

TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.

Note: At this point no input is supported

Note: multiple authors have contributed to this patch:
Authored-by: Robert Bragg <robert@linux.intel.com>
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Rico Tzschichholz.
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
2013-08-10 19:13:48 -04:00
Robert Bragg
531be6c413 Track the X Shape input region and use it for picking
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
2013-08-10 19:13:48 -04:00
Dan Winship
7a4c808e43 display: clean up focus_window vs expected_focus_window
Mutter previously defined display->focus_window as the window that the
server says is focused, but kept display->expected_focus_window to
indicate the window that we have requested to be focused. But it turns
out that "expected_focus_window" was almost always what we wanted.

Make MetaDisplay do a better job of tracking focus-related requests
and events, and change display->focus_window to be our best guess of
the "currently" focused window (ie, the window that will be focused at
the time when the server processes the next request we send it).

https://bugzilla.gnome.org/show_bug.cgi?id=647706
2013-05-22 13:46:15 -04:00
Owen W. Taylor
97a4cc8c9b Make handling of windows that don't respond to _NET_WM_SYNC_REQUEST reliable
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.

Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 08:01:28 -04:00
Owen W. Taylor
592374bc62 Fix freezing of windows with keyboard resizing
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.

Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 07:59:57 -04:00
Ray Strode
2cafb8be2d window: fix meta_window_is_remote across hostname changes
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).

Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.

This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.

https://bugzilla.gnome.org/show_bug.cgi?id=688716
2013-02-20 16:02:10 -05:00
Owen W. Taylor
5876f2e3e5 Fix corner cases where _NET_WM_FRAME_DRAWN might be missed
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.

https://bugzilla.gnome.org/show_bug.cgi?id=693833
2013-02-14 16:21:26 -05:00
Owen W. Taylor
87fe9685b5 Distinguish "no delay" frames from spontaneous drawing
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.

Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:

 - Increment by 1: a no-delay frame
 - Increment by more than 1: a non-urgent frame, handle normally

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
fbfab93c63 Send _NET_WM_FRAME_DRAWN messages
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
70c0d39fa7 Add support for an extended style of _NET_WM_SYNC_REQUEST_COUNTER
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7743c70d47 Move sync alarms to be per-window and permanent
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:25 -05:00
Owen W. Taylor
c9343e3ee3 Implement freezing of updates during resize
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:40:07 -05:00
Jasper St. Pierre
a613a55658 Support _NET_WM_OPAQUE_REGION
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:08:04 -05:00
Jasper St. Pierre
093e101252 Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:03:47 -05:00
Jasper St. Pierre
6f873be7fa Revert "Make work_area calculation funcs public and introspectible"
This reverts commit d8058138ab.
2013-02-06 00:03:10 -05:00
Jasper St. Pierre
d8058138ab Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-05 23:54:13 -05:00
Adel Gadllah
9a57626556 meta-window-actor: Change unredirection hints to match spec changes
Change the bypass / dont_bypass compositor code to match the latest
spec.

https://bugzilla.gnome.org/show_bug.cgi?id=693064
2013-02-03 14:29:45 +01:00
Florian Müllner
30bdadb519 window: Cache _NET_WM_ICON_GEOMETRY
Rather than doing a server round trip each time when retrieving the
icon geometry, use the existing property mechanism to cache it.

https://bugzilla.gnome.org/show_bug.cgi?id=692997
2013-02-01 15:08:38 +01:00
Jasper St. Pierre
d8eb47e2b7 window: Make meta_window_located_on_workspace() public
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
2013-01-18 15:45:05 -05:00
Adel Gadllah
3876a1a192 Support bypass compositor hints
Add support for _NET_WM_BYPASS_COMPOSITOR and _NET_WM_DONT_BYPASS_COMPOSITOR
as proposed here: https://mail.gnome.org/archives/wm-spec-list/2012-February/msg00010.html

https://bugzilla.gnome.org/show_bug.cgi?id=683020
2012-12-18 19:02:34 +01:00
Jasper St. Pierre
1d827049d6 Port mutter to use XInput2 events instead of Core Events
Mechanically transform the event processing of mutter to care
about XI2 events instead of Core Events. Core Events will be left
in the dust soon, and removed entirely.

https://bugzilla.gnome.org/show_bug.cgi?id=688779
2012-12-13 14:56:25 -05:00
Jasper St. Pierre
881d256ce0 window: Move grab op sync handling code out
This removes some duplicate event type checks, and will make
the code cleaner in the future when we want to make the grab_op_event
handler take an XIDeviceEvent directly.

Based on a patch by Owen Taylor <otaylor@fishsoup.net>

https://bugzilla.gnome.org/show_bug.cgi?id=688779
2012-12-13 14:56:24 -05:00
Jasper St. Pierre
18b38320a6 window: Make some window methods public
There's no reason they aren't, right now. Extensions should be able
to use these.

https://bugzilla.gnome.org/show_bug.cgi?id=678126
2012-06-25 13:52:47 -04:00
Rui Matos
2926323a9a window: Introduce meta_window_get_tile_match()
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
2012-03-16 19:12:05 +01:00
Ryan Lortie
1772a2a59c adjust to new Gtk properties for app menu
https://bugzilla.gnome.org/show_bug.cgi?id=668118
2012-01-18 17:26:12 -05:00
Florian Müllner
9729a99ec5 window: Support GTK+'s hide-titlebar-when-maximized hint
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.

https://bugzilla.gnome.org/show_bug.cgi?id=665617
2011-12-15 16:37:20 +01:00
Ryan Lortie
e4ed433e18 Add _DBUS_UNIQUE_NAME and _OBJECT_PATH properties
https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:21:22 -05:00
Colin Walters
8ab5cc8f19 Load _DBUS_APPLICATION_ID property, expose it via API
This is used to associate GtkApplication -> X window, and will
be consumed by gnome-shell.

https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:12:31 -05:00
Florian Müllner
baeb9fbc4b window: Make meta_window_can_tile_side_by_side() public
In order to support keybindings for window tiling, we need to
determine whether a window is tilable or not, so make this public.

https://bugzilla.gnome.org/show_bug.cgi?id=648700
2011-12-12 11:55:51 +01:00
Florian Müllner
bed9cb1648 window: Keep track of the last full-maximization state
In order to be able to toggle between tiled and normal/maximized
states, we need to keep track of the last full maximization state.

https://bugzilla.gnome.org/show_bug.cgi?id=648700
2011-12-12 11:55:50 +01:00
Rui Matos
138eb1e3b4 tiling: keep track of the monitor where a window was tiled
meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.

When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=642580
2011-10-18 02:40:36 +01:00
Rui Matos
c39129b6e8 tiling: for tiled maximization use the tile area as target size/position
When using more than one monitor, tiled maximization can be triggered with the
pointer in one monitor while most of the window area remains in another. This
means that the maximization constraint would maximize the window into the wrong
monitor as it uses the work area size/position as target.

Fix this by using the current tile area as target size/position.

https://bugzilla.gnome.org/show_bug.cgi?id=657519
2011-10-18 02:33:41 +01:00
Alexander Larsson
19b6888ea5 When monitors change, keep windows on same output.
If XRANDR is availible, we track the first (or primary) output per
crtc (== xinerama monitor) so when the monitors change we can try
to find the same output and move windows there. If we can't find the
original monitor in the new set (or XRANDR is not supported) we move
the window to the primary monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=645408
2011-09-14 15:38:55 +02:00