summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* display: move more event handling to clutterwip/focusGiovanni Campagna2014-02-272-299/+95
| | | | | | | | | | 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.
* MetaSurfaceActor: add a generic hook to retrieve the MetaWindowGiovanni Campagna2014-02-275-6/+32
| | | | | This way we can find the window for a ClutterEvent even when running as an x11 compositor.
* compositor: fix mouse interactions on framesGiovanni Campagna2014-02-272-4/+10
| | | | | | | | | | 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)
* keybindings: fix per window keybindingsGiovanni Campagna2014-02-272-50/+21
| | | | | | | | We must spoof events to clutter even if they are associated with a MetaWindow, because keyboard events are always associated with one (the focus window), and we must process keybindings for window togheter with the global ones if they include Super, because we're not going to see them again.
* display: Always use the key focused window for key eventsJasper St. Pierre2014-02-271-0/+10
| | | | We no longer grab the actor's key focus, so this is necessary.
* display: Don't grab the window actor's key focusJasper St. Pierre2014-02-271-10/+0
| | | | This breaks gnome-shell's actor tracking code.
* display: Return TRUE when we've handled an X event appropriatelyJasper St. Pierre2014-02-271-14/+27
| | | | | We need to do this to make sure events aren't improperly sent to Clutter in the next commit.
* display: Simplify checks to see if a window is the root windowJasper St. Pierre2014-02-271-8/+5
|
* Revert "window-actor: Complete the removal of update_shape"Jasper St. Pierre2014-02-261-0/+39
| | | | This reverts commit 640102c03b1e74ad481076cefe15b974ceeee052.
* Revert "window: Update the shape, input, and opaque regions immediately"Jasper St. Pierre2014-02-265-41/+10
| | | | This reverts commit c0d791cd6e25915a36890891940803185f7cc808.
* window-actor: Complete the removal of update_shapeJasper St. Pierre2014-02-261-39/+0
| | | | | I accidentally stashed the rest of the stuff and forgot to commit it... oops.
* window: Update the shape, input, and opaque regions immediatelyJasper St. Pierre2014-02-265-10/+41
| | | | | | | | ... and individually. It turns out that updating the opaque region was causing the shape region to be updated, which was causing a new shape mask to be generated and uploaded to the GPU. Considering GTK+ regenerates the opaque region on pretty much any focus change, this is not good.
* window-actor: Kill off another use of MetaFrameBordersJasper St. Pierre2014-02-261-3/+3
|
* window-actor: Don't pass around client_areaJasper St. Pierre2014-02-261-17/+19
| | | | | | To solve a performance regression, the three update_*_region calls are going to be split up, so just call get_client_area_rect in the methods itself.
* window: Add meta_window_get_client_area_rectJasper St. Pierre2014-02-263-10/+35
|
* window-x11: Add back missing error trapJasper St. Pierre2014-02-261-0/+1
| | | | This was accidentally removed in 9f5087e.
* keybindings: fix invalid read after a keybinding is removedGiovanni Campagna2014-02-262-1/+5
| | | | | | | | | The handler pointer is dangling in MetaKeyBinding until rebuild_key_binding_table() is run, so we can't dereference it. Because we only need the flags at ungrab time, store a copy in the MetaKeyBinding structure. https://bugzilla.gnome.org/show_bug.cgi?id=724402
* window-actor: Fix cullingAdel Gadllah2014-02-261-0/+1
| | | | | | | | At some point meta_window_actor_cull_out stopped calling meta_cullable_cull_out_children which caused the unobscured region to never be set for the stex. https://bugzilla.gnome.org/show_bug.cgi?id=725216
* window: fix loading the window type initiallyGiovanni Campagna2014-02-261-0/+3
| | | | This code was lost in the window/window-x11 split.
* MetaWindowX11: fix listening for shape eventsGiovanni Campagna2014-02-251-0/+5
| | | | | This code was lost when support for input shapes was originally introduced.
* Fix input and bounding shapesGiovanni Campagna2014-02-252-23/+50
| | | | | | | | | | | | | | For decorated windows, we don't want to apply any input shape, because the frame is always rectangular and eats all the input. The real check is in meta-window-actor, where we consider if we need to apply the bounding shape and the input shape (or the intersection of the two) to the surface-actor, but as an optimization we avoid querying the server in meta-window. Additionally, for undecorated windows, the "has input shape" check is wrong if the window has a bounding shape but not an input shape.
* MetaWindowActor: survive having no MetaSurfaceActorGiovanni Campagna2014-02-255-22/+73
| | | | | | | | | | We need a MetaWaylandSurface to build a MetaSurfaceActor, but we don't have one until we get the set_window_xid() call from XWayland. On the other hand, plugins expect to see the window actor right from when the window is created, so we need this empty state. Based on a patch by Jasper St. Pierre.
* MetaSurfaceActor: move freeze accounting to MetaWindowActorGiovanni Campagna2014-02-253-36/+26
| | | | | | | Turns out we only ever need to freeze/thaw whole windows, not surfaces or subsurfaces. This will allow removing the surface actor without losing the count.
* wayland-surface: Rework construction / destruction yet againJasper St. Pierre2014-02-244-32/+72
| | | | | | | | | | | | | This time, to make way for MetaSurfaceActorEmpty. This also fixes destroy effects as a side effect. It still has issues if we try to re-assign an actor that's already toplevel (e.g. somebody re-popping up a menu that's already being destroyed), but this will be fixed soon. The idea here is that MetaWindowActor will do the unparenting of the surface actor when it itself is destroyed. To prevent bad issues with picking, we only make the surface actor reactive when it's toplevel.
* Revert "window: Delay the showing of XWayland clients until set_window_id"Jasper St. Pierre2014-02-242-10/+1
| | | | This reverts commit 59c8b949ad1b8712be7f1e90f8aaddac897da463.
* Revert "compositor: Delay meta_compositor_add_window until the first show"Jasper St. Pierre2014-02-242-12/+21
| | | | This reverts commit 4efe4483fbc7602e8358fda936074216a8e5544b.
* stack-tracker: Comment out bad warningJasper St. Pierre2014-02-241-1/+1
| | | | | | It triggers too often, making G_DEBUG=fatal-warnings quite useless. Owen is going to rewrite this code sometime in the near future, so I'm just gonna kill this warning for now.
* core: prevent early MetaIdleMonitor destruction when its invoker vanishesCarlos Garnacho2014-02-241-0/+2
| | | | | | | | | | | | | If the last reference of a MetaIdleMonitor is held by the caller, it may happen that the last reference is lost when calling the GDestroyNotify, if this happens when the watched DBus name vanishes, the object (and the watches hashtable) are destroyed while manipulating the watches hashtable, so bad things may happen then. Fix this by wrapping the operation by a ref/unref pair, so the object would be destroyed after operating on the hashtable. https://bugzilla.gnome.org/show_bug.cgi?id=724969
* compositor: The stage is always focused when we're a Wayland compositorJasper St. Pierre2014-02-231-0/+3
| | | | | | | | | | | | | | | | gnome-shell has some complex tracking to set the X input focus correctly, assuming various things about how the stage is set up in X11. For instance, it assumes that all actors that get key focus are gnome-shell Chrome actors that will get events through the stage, so when one of them is focused, it will try to set the focus back to the stage. In Wayland, windows are considered chrome actors that will get key events through the stage, so this only has the result of unfocusing any windows that have just received key focus. We should probably move this input focus moving to mutter instead of gnome-shell so we can better use mutter's internal state and heuristics.
* Revert "compositor: fix focusing the stage window"Jasper St. Pierre2014-02-233-78/+34
| | | | | | This reverts commit 876f81db12d122ce2be69395c809d9835eebea39. This doesn't quite work properly, and is overcomplicated.
* pointer/keyboard: Fix segfault once moreJasper St. Pierre2014-02-232-4/+10
| | | | | If the resource is destroyed before the surface, then we'll kill ourselves. Why can I never seem to write these correctly...
* pointer/keyboard: Unset focus_resource when the surface is destroyedJasper St. Pierre2014-02-222-0/+6
| | | | | focus_resource is supposed to be set only if focus_surface is as well.
* meta-window-actor: Fix paint_volumeAdel Gadllah2014-02-211-3/+3
| | | | | | | | | | | | We cannot intersect the the complete volume with the unobscured bounds because it does not include the shadows. So just intersect it with the windows's shape bounds and union it with the shadow bounds. This also matches what the comment in the code says: "We could compute an full clip region as we do for the window texture, but the shadow is relatively cheap to draw, and a little more complex to clip, so we just catch the case where the shadow is completely obscured and doesn't need to be drawn at all."
* mutter-wayland: Add XKB VT switching keysyms.Jasper St. Pierre2014-02-211-7/+7
| | | | | | | | It turns out XKB has keysyms for these for no real reason, and I was hitting those instead of the <Primary><Alt>F1 path. This is ridiculous, but key, so is the entirety of XKB. This took an embarassingly long time to figure out and debug.
* surface-actor-x11: Recreate damage when the toplevel X window changesJasper St. Pierre2014-02-202-30/+26
|
* window-actor: Split into two subclasses of MetaSurfaceActorJasper St. Pierre2014-02-2011-553/+1011
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* window-actor: Kill off needs_pixmapJasper St. Pierre2014-02-201-14/+6
| | | | | | | | It's mostly equivalent to the case where we've already detached the pixmap, *except* for the x11_size_changed case. We can simply detach the pixmap at the time the window changes size, though. https://bugzilla.gnome.org/show_bug.cgi?id=720631
* window-actor: Don't queue a redraw when queueing a new pixmapJasper St. Pierre2014-02-201-25/+3
| | | | | | | | | | | | | | | | We guarantee ourselves that a valid pixmap will appear any time that the window is painted. The window actor will be scheduled for a repaint if it's added / removed from the scene graph, like during construction, if the size changes, or if we receive damage, which are the existing use cases where this function is called. So, I can't see any reason that we queue a redraw in here. With the split into surface actors, we don't have an easy place we can use to queue a redraw, and since it's unnecessary, we can just drop it on the floor. https://bugzilla.gnome.org/show_bug.cgi?id=720631
* pointer/keyboard: Properly handle destructionJasper St. Pierre2014-02-202-25/+13
| | | | | | | | | If the client destroys the pointer resource, we shouldn't unfocus the surface, and we should regrab it when the client gets the pointer resource again. This also fixes a crash at surface destruction because of the unchecked wl_link_remove that will happen on both pointer and surface destroy.
* Bump version to 3.11.903.11.90-waylandFlorian Müllner2014-02-192-1/+12
| | | | Update NEWS.
* Make tile preview a compositor plugin effectStefano Facchini2014-02-1915-279/+216
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=665758
* pointer/keyboard: fix setting focusMarek Chalupa2014-02-192-8/+6
| | | | Set focus to NULL after using the variable
* window-actor: Fix buildJasper St. Pierre2014-02-191-1/+1
| | | | I'm bad.
* window-actor: Kill off a nonsensical edge caseJasper St. Pierre2014-02-181-10/+4
| | | | | | | | | | We can never have a window actor that represents either the X root window or the stage window, so it doesn't make sense to bail out early in case we do. I'd imagine that this came from a much earlier version of the code where the compositor was much separate and had its own MapNotify handling.
* pointer: Don't send modifiers on mouse enterJasper St. Pierre2014-02-182-53/+3
| | | | | I talked to Kristian about this. It should be enough to simply send it when we activate the surface and give it keyboard focus.
* pointer: Make the code here a bit clearerJasper St. Pierre2014-02-181-4/+7
|
* pointer/keyboard: Fix focus setting once againJasper St. Pierre2014-02-182-95/+95
| | | | Yet another large-scale restructuring... this is some messy code.
* wayland: Tie activate / deactivate to appears-focusedJasper St. Pierre2014-02-182-4/+8
| | | | ... rather than actual focus. This makes things behave better.
* wayland: Remove width / height from MetaWaylandBufferJasper St. Pierre2014-02-182-7/+4
| | | | They're in the texture.
* Revert "wayland: Explicitly destroy the surface actor"Jasper St. Pierre2014-02-181-1/+0
| | | | | | | | | | | | This reverts commit 283a81eac0a2012ed7b1b9e758a5c5ab166d3863. This can't be done yet, as it will crash when we try to do a destroy effect from a plugin. The surface actor needs to outlive the surface in this case. Though, the unparenting happening is wrong anyway for a destroy effect. We need to figure out a sane way of doing this unparenting only after all effects have finished.
View Lorry Controller Status