gnome-shell:wip/rstrode/mouse-freeze-fix

Last commit made on 2018-12-10
Get this branch:
git clone -b wip/rstrode/mouse-freeze-fix https://git.launchpad.net/gnome-shell

Branch merges

Branch information

Name:
wip/rstrode/mouse-freeze-fix
Repository:
lp:gnome-shell

Recent commits

a80e16d... by Ray Strode <email address hidden>

popupMenu: block input events when menu is closing

At the moment gnome-shell can get really confused if a menu is
fading out and gets clicked.

It can lead to mouse pointer input getting stuck until the shell
is restarted.

This commit addresses the problem by ignoring input events that
come in when the menu is closing.

616852c... by Ludovico

thunderbolt: fix missing variable underscore for `enrolling`

The variable `this.enrolling` is a typo because it has not been defined
before and is also never used.
`this._enrolling` is what it was meant to be.

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

messageTray: Re-enable unredirection when banner is destroyed

The intention of commit 4dc20398 was to disable unredirection while
banners are shown, but the ::done-displaying signal currently used for
re-enabling unredirection is only emitted under some circumstances, so
it's possible that unredirection is left disabled indefinitely, whoops.

Fix this by tying disabling unredirection explicitly to the lifetime
of the banner actor.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/799

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

st: Avoid integer overflow on unpremultiply

When computing the effective border color, we operate on colors with
premultiplied alpha to simplify the calculations, then unpremultiply
the result. However we miss a bounds check in the last check, so any
color component can overflow the allowed maximum of 0xff and shift the
result in unexpected ways.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/305

6743c18... by Cosimo Cecchi <email address hidden>

StWidget: don't forget to invalidate the paint state if not on stage

If the actor is not on the stage yet (i.e. does not have a theme
node), but has a paint state cached, we currently fail to invalidate
it, which will lead to the actor painting with old contents once it
gets onto the stage.

This commit fixes the issue by changing our invalidation strategy;
previously we were looking at the widget's own theme node to determine
if it should be invalidated or not.
Now we look at the theme nodes of our cached paint states. When the
widget is mapped on stage, those are the same as the widget's own
theme node, but when the widget is not on the stage, we'll still be
able to invalidate them.

As part of this, we move the invalidation API to StThemeNodePaintState,
which is a more natural place for our use case.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/314

4d649d6... by Daniel Mustieles <email address hidden>

Updated Spanish translation

121c427... by Matej Urbančič

Updated Slovenian translation

25fbffc... by Kristjan SCHMIDT

Update Esperanto translation

0e0574a... by Daniel van Vugt

iconGrid: Eliminate JavaScript for painting/picking

The only reason for `vfunc_paint` and `vfunc_pick` existing was to
implement a culling optimization. Although that optimization actually
made performance worse than none at all because it forced the painting
and picking cycles to spend more time calling into JavaScript.

Turns out we don't have to choose between native code and culling though.
Just reimplement the culling using native ClutterActor functions and we
get the benefits of both.

Performance on an i7-7700:

Moving the cursor over the icon grid:
Before: 70% CPU, 5.5ms per frame
After : 60% CPU, 4.5ms per frame

Scrolling the icon grid:
Before: 60% CPU, 4.4ms per frame
After : 50% CPU, 3.3ms per frame

Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/174

4c11d15... by Marco Trevisan (Treviño)

st-button: Ignore pointer emulated touch events

In X11, pointer emulated touch events are replicated with normal PRESS, RELEASE
pair events which are generated by the server. Thus for a single tap we get:
 - TOUCH_BEGIN -> TOUCH_END, PRESS -> RELEASE

This will cause st-button to send two "clicked" signals, instead of just one,
breaking extensions (like dash-to-dock) that show buttons in the main stage
which will be checked two times or that will receive the same signal two times.