mutter:gnome-3-18

Last commit made on 2016-10-29
Get this branch:
git clone -b gnome-3-18 https://git.launchpad.net/mutter

Branch merges

Branch information

Name:
gnome-3-18
Repository:
lp:mutter

Recent commits

b1b46f1... by liushuyu <liushuyu_011@126.com>

Update zh_CN translation

3082504... by =?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>

Bump version to 3.18.4

Update NEWS.

8a52912... by =?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>

Shut up some compiler warnings

54a6802... by =?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>

Do not skip CoglError parameters

While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible (i.e. any CoglError
that is not a malformed blend string).

https://bugzilla.gnome.org/show_bug.cgi?id=765058

e6d414e... by =?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>

Do not try to unref NULL CoglObjects

https://bugzilla.gnome.org/show_bug.cgi?id=765058

70f20c9... by Rui Matos

Handle meta_screen_get_monitor_for_point() returning NULL

On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.

Commit 4bebc5e5fa8aade8a96c769bf2365abe0948f6ce introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.

https://bugzilla.gnome.org/show_bug.cgi?id=763159

b5f7005... by Cédric VALMARY (Tot en òc)

Updated Occitan translation

f0e2e23... by =?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>

Bump version to 3.18.3

Update NEWS.

0c48a26... by Jasper St. Pierre

window-x11: Fix checks for a bounding region input region

When cleaning up the logic in commit c408cf7, I forgot to properly apply
de Morgan's laws to an inverse.

Reported by ricotz on IRC.

(cherry picked from commit 6fc51e3723b08d99701cbb9f912adc230dec072a)

26a18e8... by Rui Matos

x11/window: Ensure we send a ConfigureNotify to just mapped windows

When managing a non-OR window we're required by the ICCCM to behave as
if we received a ConfigureRequest which means that we must generate a
synthetic ConfigureNotify even if the window isn't moved or resized
from its current (initial) geometry.

During MetaWindow's x11/wayland split a slight behavior change for x11
windows crept in. Before the code split, MetaWindow->rect was
initialized with the X window's geometry, but now we're not
initializing MetaWindowX11Private->client_rect which causes the checks
for whether it's necessary to move/resize the window in
meta_window_x11_move_resize_internal() to tell us that we do need to
move/resize which means we do an XConfigureWindow() call and don't
send the sythetic ConfigureNotify. But since the X window isn't really
moving, the XConfigureWindow() call doesn't cause the X server to
generate a ConfigureNotify which breaks some clients such as Java's
AWT.

We can fix this by setting MetaWindowX11Privatew->client_rect for both
OR and non-OR windows. We can set buffer_rect for non-OR windows as
well to simplify the code since it will be assigned the correct value
in meta_window_x11_move_resize_internal() .

https://bugzilla.gnome.org/show_bug.cgi?id=759492