Commit Graph

267 Commits

Author SHA1 Message Date
Jasper St. Pierre
81eb7d9537 Add META_GRAB_OP_WAYLAND_CLIENT
Which is used for Wayland popup grabs.

The issue here is that we don't want the code that raises or focuses
windows based on mouse ops to run while a client has a grab.

We still keep the "old" grab infrastructure in place for now, but
ideally we'd replace it eventually with a better grab-op infrastructure.
2014-03-10 15:11:03 -04:00
Rui Matos
674bcef6da Handle mouse-button-modifier being disabled
In case 'mouse-button-modifier' is disabled the mask is 0 which means
we would always grab.
2014-02-28 14:55:14 +01:00
Giovanni Campagna
98e3e5e50f Partially revert 5c99eae8a9
We must extract the window from XIDeviceEvent, to be able
to apply our workaround to spoof the event in compositor.c
2014-02-27 23:49:56 +01:00
Jasper St. Pierre
9e51d98f4a Remove tabpopup and friends
These are unused in gnome-shell, and add complexity. Remove them.
2014-02-27 13:55:58 -05:00
Giovanni Campagna
5c99eae8a9 display: clean up event handling
The only events we handle as XIEvents are FocusIn/Out, Enter and
Leave.  Motion, ButtonPress/Release, KeyPress/Release are handled
through clutter instead.
Among other things, this means we don't need to fake motion compression
by peeking over gdk event queue...
2014-02-27 14:57:52 +01:00
Giovanni Campagna
89aa5df711 display: fix inverted check from 75184d4c55
I noticed it, Jasper noticed it, we agreed to change it, and then
I forgot to do it before pushing...
2014-02-27 14:45:10 +01:00
Giovanni Campagna
b00fa70d91 display: move more event handling to clutter
Mouse event handling was duplicated, resulting in weird interactions
if clutter was allowed to see certain events (for example under
wayland, where it gets all events). Because now clutter sees all
X events, even when running as an x11 compositor, we can handle
everything using the clutter variants.
At the same time, rewrite a little the passive button grab code,
to make it clear what is being matched on what and why.
2014-02-27 03:13:33 +01:00
Giovanni Campagna
360d423faa MetaSurfaceActor: add a generic hook to retrieve the MetaWindow
This way we can find the window for a ClutterEvent even when
running as an x11 compositor.
2014-02-27 03:13:33 +01:00
Jasper St. Pierre
23b0f7be43 display: Always use the key focused window for key events
We no longer grab the actor's key focus, so this is necessary.
2014-02-27 03:13:32 +01:00
Jasper St. Pierre
7f195aec7a display: Don't grab the window actor's key focus
This breaks gnome-shell's actor tracking code.
2014-02-27 03:13:32 +01:00
Jasper St. Pierre
da13e3d237 display: Return TRUE when we've handled an X event appropriately
We need to do this to make sure events aren't improperly sent
to Clutter in the next commit.
2014-02-27 03:13:32 +01:00
Jasper St. Pierre
75184d4c55 display: Simplify checks to see if a window is the root window 2014-02-27 03:13:32 +01:00
Jasper St. Pierre
f860df4b2d Revert "compositor: fix focusing the stage window"
This reverts commit 876f81db12.

This doesn't quite work properly, and is overcomplicated.
2014-02-23 12:34:52 -05:00
Jasper St. Pierre
83aca0b53d window-actor: Split into two subclasses of MetaSurfaceActor
The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:

  * X11 compositor. In this case, we're a traditional X11 compositor,
    not a Wayland compositor. We use XCompositeNameWindowPixmap to get
    the backing pixmap for the window, and deal with the COMPOSITE
    extension messiness.

    In this case, meta_is_wayland_compositor() is FALSE.

  * Wayland clients. In this case, we're a Wayland compositor managing
    Wayland surfaces. The rendering for this is fairly straightforward,
    as Cogl handles most of the complexity with EGL and SHM buffers...
    Wayland clients give us the input and opaque regions through
    wl_surface.

    In this case, meta_is_wayland_compositor() is TRUE and
    priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.

  * XWayland clients. In this case, we're a Wayland compositor, like
    above, and XWayland hands us Wayland surfaces. XWayland handles
    the COMPOSITE extension messiness for us, and hands us a buffer
    like any other Wayland client. We have to fetch the input and
    opaque regions from the X11 window ourselves.

    In this case, meta_is_wayland_compositor() is TRUE and
    priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.

We now split the rendering logic into two subclasses, which are:

  * MetaSurfaceActorX11, which handles the X11 compositor case, in that
    it uses XCompositeNameWindowPixmap to get the backing pixmap, and
    deal with all the COMPOSITE extension messiness.

  * MetaSurfaceActorWayland, which handles the Wayland compositor case
    for both native Wayland clients and XWayland clients. XWayland handles
    COMPOSITE for us, and handles pushing a surface over through the
    xf86-video-wayland DDX.

Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-20 14:44:31 -05:00
Jasper St. Pierre
1e6b3faa83 Fix the input region not working properly
The input region was set on the shaped texture, but the shaped texture
was never picked properly, as it was never set to be reactive. Move the
pick implementation and reactivity to the MetaSurfaceActor, and update
the code everywhere else to expect a MetaSurfaceActor.
2014-02-18 21:29:23 -05: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
aec3edb1cc Always map the client and frame windows
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.

However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.

I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.

Remove this now.

The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.

At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-14 23:19:41 -05:00
Jasper St. Pierre
6b66553493 display: Remove unused variable 2014-02-09 11:53:15 -05:00
Jasper St. Pierre
6561b53346 display: Clean up screen management code 2014-02-07 19:52:34 -05:00
Jasper St. Pierre
3e73babaf7 display: Clean up creation of the guard window a bit...
Do it consistently in all code paths...
2014-02-03 17:33:52 -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
Jasper St. Pierre
c8d185fc74 display: Revise Wayland event handling
X11 window frames use special UI grab ops, like META_GRAB_OP_CLICKING_MAXIMIZE,
in order to work properly. As the frames in this case are X11 clients, we need
to pass through X events in this case. So, similar to how handle_xevent works,
use two variables, bypass_clutter, and bypass_wayland, and set them when we
handle specific events.
2014-02-01 11:54:47 -05:00
Jasper St. Pierre
20545941fa Revert unintentional merge from wip/surface-content to wayland
This reverts a lot of commits.
2014-01-22 09:18:13 -05:00
Jasper St. Pierre
8e6f8087e8 Always map the client and frame windows
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.

However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.

I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.

Remove this now.

The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. Theoretically, we might want to
show previews of shaded windows in the overview and Alt-Tab, so we remove
the complex unmap tracking for this later.
2014-01-21 19:01:18 -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
577624adef Reduce server grabs during window creation
Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.

During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.

When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).

The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.

Now that there are no grabs we don't have to worry about explicitly calling
display_notify_window after grabs have been dropped. Fold that into
meta_window_new_shared().

https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-07 07:53:16 -06:00
Daniel Drake
becbad56ef Discourage server grabs
Server grabs are not as evil as you might expect, but there is agreement
in that their usage should be limited.

Server grabs can cause things to go rather wrong when mutter emits
a signal while it has grabbed the server. If the receiver of that signal
waits for a synchronous action performed by another client, then you
have a deadlock. This happens with Mali binary GLESv2 drivers :(

https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-07 07:17:09 -06: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
Owen W. Taylor
9c1b972ca1 Fix problems with focus tracking
When a client spontaneously focuses their window, perhaps in response
to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
Updating display->focus_serial in response to FocusOut then was causing
us to ignore FocusIn and think that the focus was not on any window.

We need to distinguish this spontaneous case from the case where we
set the focus ourselves - when we set the focus ourselves, we're careful
to combine the SetFocus with a property change so that we know definitively
what focus events we have already accounted for.

https://bugzilla.gnome.org/show_bug.cgi?id=720558
2013-12-18 09:46:08 -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
309f78ff52 display: Fix window pings
These are 32-bit values, not longs. Treat them as such.
2013-12-06 20:03:46 -05:00
Jasper St. Pierre
283649b8d7 Support keybindings again, too 2013-12-05 17:18:49 -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
58b39233f5 display: Correct the detection of a grab
The grab_window might be NULL, in which case we have a full-screen
grab, but we might still in a grab. Correct the check by asking
whether we're in a grab op or not.
2013-12-05 17:18:49 -05:00
Jasper St. Pierre
82066e02c5 display: Set the cursor when calling XIGrabDevice again 2013-12-05 17:18:49 -05:00
Jasper St. Pierre
eec0f5df47 display: Fix logic for determining whether our focus was successful
In some cases, we can focus the frame window instead of the client
window, so make sure that our checks include that as well.

https://bugzilla.gnome.org/show_bug.cgi?id=715030
2013-11-25 15:14:18 -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
Florian Müllner
3025cb7c48 display: Remove unused variables 2013-11-19 20:12:51 +01:00
Florian Müllner
17f48baf3a display: Tweak code to work around a compiler warning
The compiler is not quite smart enough to figure out that the condition
for setting the "compositor" variable matches a later condition for
accessing it, so express this in a way the compiler will understand.
2013-11-19 20:08:46 +01:00
Owen W. Taylor
b9da43b753 Rename meta_window_get_outer_rect() to meta_window_get_frame_rect()
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
2013-11-19 14:04:16 -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
Owen W. Taylor
f36a627330 Use utility functions to convert between frame and client rectangles
There are extensive places in the code where we convert between the client
rectangle and the frame rectangle. Instead of manually doing it use
new helper functions on MetaWindow and the existing meta_window_get_outer_rect().

This fixes a number of bugs where the computation was being done incorrectly,
most of these bugs are with the recently added custom frame extents, but
some relate to invisible borders or even simply to confusion between the
window and frame rectangle.

Switch the placement code to place the frame rectangle rather
than the client window - this simplifies things considerably.

https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-19 14:04:16 -05:00
Jasper St. Pierre
82cb4e8267 display: Don't focus the no-focus-window when sending WM_TAKE_FOCUS to a globally active window
Clients like on-screen keyboards try not to take focus when the user clicks
on their window by setting the Input hint to false. However, due to GTK+ and
GDK bugs, the public API for setting the Input hint to false don't remove
WM_TAKE_FOCUS from WM_PROTOCOLS, unintentionally putting them into Globally
Active mode.

These clients also expect that since they don't want to take focus, they want
the focus to remain on the existing window. In this case, for clients like
on-screen keyboards, it's so they can send synthesized keyboard events to the
focused window.

https://bugzilla.gnome.org/show_bug.cgi?id=710296
2013-11-19 13:46:34 -05:00
Jasper St. Pierre
bbbb9ac53c display: Make handle_[x]event private 2013-11-18 21:19:00 -05:00
Jasper St. Pierre
4091f5493d cursor-tracker: Force the grab cursor on grab ops
This makes window moving have a 'window move' cursor, and similar.
2013-11-18 19:34:24 -05:00
Jasper St. Pierre
1f569bef76 Fix dragging on move/resize grabs
We need to use the grab_window for incoming events if we have an active grab.
2013-11-18 18:38:24 -05:00
Jasper St. Pierre
cf181fe109 display: Adapt to new clutter event filter API 2013-11-14 14:34:53 -05:00