Commit Graph

6 Commits

Author SHA1 Message Date
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
Giovanni Campagna
394b44a2c2 compositor: fix mouse interactions on frames
meta_ui_window_is_widget() returns FALSE for frame windows, so we
must filter those explicitly (by letting the event go to gtk
and from there to MetaFrames). Also, for proper gtk widgets
(window menus) we want to let gtk see all events, including
keyboard, otherwise we break keynav in the window menu.
This means that having a window menu open disables keybindings
(because the event doesn't run through clutter)
2014-02-27 03:13:32 +01:00
Jasper St. Pierre
020cfa7283 surface-actor-x11: Recreate damage when the toplevel X window changes 2014-02-20 14:50:48 -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
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
e6391c2896 surface content 2014-01-21 19:01:34 -05:00