Commit Graph

135 Commits

Author SHA1 Message Date
Jasper St. Pierre
3de58189c0 window: Remove an unused bit 2014-03-18 13:18:52 -04:00
Jasper St. Pierre
5270c469a3 window: Remove meta_window_set_gravity as "public" API 2014-03-18 11:24:24 -04:00
Jasper St. Pierre
cdfc6f5b53 window: Remove vfunc slots for signals
These aren't used currently, and we're going to be adding
more vfuncs.
2014-03-18 11:24:24 -04:00
Jasper St. Pierre
f5bd7c5f50 window: Remove bogus comment
These fields haven't been around for quite some time.
2014-03-18 11:24:16 -04:00
Jasper St. Pierre
cb549154aa window: Move meta_window_configure_notify to window-x11 2014-03-18 11:24:16 -04:00
Jasper St. Pierre
1f15c85c00 window: Make window_is_terminal private 2014-03-18 10:25:54 -04:00
Jasper St. Pierre
535685742a window: Export is_title_onscreen and shove_title_onscreen as well
This was fixed in the master version of the commit, but I forgot to
squash it on the Wayland branch.
2014-03-17 11:18:26 -04:00
Jasper St. Pierre
a9d8107c3d window: Replace meta_window_type_changed with meta_window_set_type
Which does the equality checking for us.
2014-03-13 17:14:28 -04:00
Jasper St. Pierre
a5d2c51392 window: Move recalc_type to window-x11.c
It's only used by the X11 codepath.
2014-03-13 17:14:28 -04:00
Owen W. Taylor
2cf80bc647 Fix identification of CSD windows when checking whether to force fullscreen
We try to exempt CSD windows from being forced fullscreen if they are
undecorated and the size of the screen; however, we also catch almost
all windows that *do* need to be forced fullscreen in this check, since
they also have decorations turned off.

Identify actual CSD windows by checking whether _GTK_FRAME_EXTENTS is set -
GTK+ will always set this on CSD windows even if they have no invisible
borders or shadows at the current time.

We explicitly turn off the legacy-fullscreen check for native wayland windows
so we don't start legacy-fullscreening them if the new
meta_window_is_client_decorated() is later made more accurate.

https://bugzilla.gnome.org/show_bug.cgi?id=723029
2014-03-11 13:02:19 -04:00
Jasper St. Pierre
ec2c3e1438 window: Add meta_window_get_client_area_rect 2014-02-26 19:54:41 -05:00
Stefano Facchini
4de3f7ca29 Make tile preview a compositor plugin effect
https://bugzilla.gnome.org/show_bug.cgi?id=665758
2014-02-19 21:55:35 +01:00
Jasper St. Pierre
e62fe956fd window: Enable pinging on Wayland windows
I implemented pinging, but never actually enabled the feature
properly on Wayland surfaces by setting the net_wm_ping hint to
TRUE, causing the fallback path to always be hit.

Rename net_wm_ping to can_ping so it doesn't take on an
implementation-specific meaning, and set it for all Wayland windows.
2014-02-18 20:30:52 -05:00
Jasper St. Pierre
57728b4322 Kill HAVE_WAYLAND 2014-02-17 21:50:32 -05:00
Jasper St. Pierre
a66060e21a Revert "Move window pings to MetaWindow"
This was a bad idea, as ping/pong has moved to a client-specific
request/event pair, rather than a surface-specific one. Revert
the changes we made here and correct the code to make up for it.

This reverts commit aa3643cdde.
2014-02-16 10:21:22 -05:00
Jasper St. Pierre
def5e86673 wayland: Add support for the set_margin request 2014-02-07 19:28:36 -05:00
Jasper St. Pierre
8905bd2280 window-x11: Move meta_window_new to window-x11.c and rename 2014-02-01 19:19:22 -05:00
Jasper St. Pierre
f7097e6f66 Start moving X11-specific code to window-x11.c
The goal here is to make MetaWindow represent a toplevel, managed window,
regardless of if it's X11 or Wayland, and build an abstraction layer up.
Right now, most of the X11 code is in core/ and the wayland code in wayland/,
but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
2014-02-01 18:39:12 -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
Daniel Drake
384a34c27d Remove meta_window_new_with_attrs
The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.

As that doesn't happen any more, we can clean up. No functional changes.

Suggested by Owen Taylor.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-07 07:17:06 -06:00
Jasper St. Pierre
8131f34eb6 Move _NET_WM_WINDOW_OPACITY handling to the standard window-props interface 2013-12-09 15:53:23 -05:00
Jasper St. Pierre
f0fa4d831a window: Add a simple meta_window_get_toplevel_xwindow utility
To replace all the places where we do:

  window->frame ? window->frame->xwindow : window->xwindow

or similar...
2013-12-09 14:05:18 -05:00
Jasper St. Pierre
fa65c380db Support X button events again
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.
2013-12-05 17:18:49 -05:00
Jasper St. Pierre
644f3e1275 window: Make setters for shape/input/opaque regions private again
Wayland now pushes these to the surface actor rather than the toplevel
MetaWindow...
2013-11-25 17:25:56 -05:00
Jasper St. Pierre
aa3643cdde Move window pings to MetaWindow
This will make it possible to use on Wayland as well...
2013-11-21 14:24:04 -05:00
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