Last commit made on 2019-10-09
Get this branch:
git clone -b upstream/latest https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/mutter
Members of Ubuntu Desktop can upload to this branch. Log in for directions.

Branch merges

Branch information


Recent commits

b1549bb... by Iain Lane on 2019-10-09

New upstream version 3.34.1

658c741... by Florian Müllner <email address hidden> on 2019-10-08

Bump version to 3.34.1

Update NEWS.

65cc8c1... by Jordi Mas on 2019-10-08

Update Catalan translation

d9597d2... by Carlos Garnacho on 2019-10-07

wayland: Ensure to forward numlock state to clients

This makes sure the numlock key lock state is forwarded to the wl_keyboard
internal state, notably on startup and after keymap changes.


fc3831c... by Carlos Garnacho on 2019-10-07

backends: Fix thinko

We are meant to pass a flagset there, not a boolean. Fixes state querying
to the ClutterKeymap in the native backend.


ce86f90... by Carlos Garnacho on 2019-10-07

Revert "backends/x11: Do not reload keymap on new keyboard notifications"

This reverts commit b01edc22f3cf816ec2bbc4e777fb44525a8456a8.

It breaks keybindings on certain physical keyboard layouts.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/822

b5f5002... by Jonas Ådahl on 2019-09-04

wayland: Untie MetaWindowXwayland lifetime from the wl_surface

For the most part, a MetaWindow is expected to live roughly as long as
the associated wl_surface, give or take asynchronous API discrepancies.

The exception to this rule is handling of reparenting when decorating or
undecorating a window, when a MetaWindow on X11 is made to survive the
unmap/map cycle. The fact that this didn't hold on Wayland caused
various issues, such as a feedback loop where the X11 window kept being
remapped. By making the MetaWindow lifetime for Xwayland windows being
the same as they are on plain X11, we remove the different semantics
here, which seem to lower the risk of hitting the race condition causing
the feedback loop mentioned above.

What this commit do is separate MetaWindow lifetime handling between
native Wayland windows and Xwayland windows. Wayland windows are handled
just as they were, i.e. unmanaged together as part of the wl_surface
destruction; while during the Xwayland wl_surface destruction, the
MetaWindow <-> MetaWaylandSurface association is simply broken.

Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762


2c388e2... by Jonas Ådahl on 2019-10-07

clutter/transition: Don't split reference counting with actor

ClutterActor took a reference in its transition 'stopped' handler,
aiming to keep the transition alive during signal emission even if it
was removed during. This is, however, already taken care of by
ClutterTimeline, by always taking a reference during its 'stopped'
signal emission, so no need to add another one.

This also has the bonus of making reference ownership simpler, as well
as avoidance of double free if an actor was destroyed before a
transition has finished.


fb6e274... by Jonas Ådahl on 2019-10-07

plugins/default: Hold reference on timelines while stopping

We get implicit, thus auto-removed, transitions, then manage them
manually by stopping them and emitting "completed" signals. This doesn't
work since they are removed and freed when stopped. To be able to emit
the "completed" signal, hold a reference while stopping, so that we
still can emit the signal as before.


6ee006c... by Jonas Ådahl on 2019-10-04

clutter/actor: Mark implicit transitions as remove-on-complete

Implicit transitions had a referenced taken while emitting the
completion signals, but said reference would only be released if it was
had remove-on-complete set to TRUE.

Change this to instead remove the 'is_implicit' state and mark all
implicit transitions as remove-on-complete. This fixes a
ClutterPropertyTransition leak in gnome-shell triggered by e.g. showing
/ hiding menus.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1740