gnome-shell:cherry-pick-a0def239

Last commit made on 2020-04-01
Get this branch:
git clone -b cherry-pick-a0def239 https://git.launchpad.net/gnome-shell

Branch merges

Branch information

Name:
cherry-pick-a0def239
Repository:
lp:gnome-shell

Recent commits

768c08b... by Marco Trevisan (Treviño)

main: Don't override DesktopAppInfo desktop if already GNOME

During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).

In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.

So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.

At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.

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

(cherry picked from commit a0def239408b389020c8d2dc634ab0250e2d9721)

69426cb... by Danial Behzadi

Update Persian translation

9f968e7... by Jonas Ådahl

appDisplay: Clear animateLater callbacks when unmapping

In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.

Fix this by removing any lingering signal or later handlers when
unmapping.

Fixes: 5c33fe4a0a4eb4ed

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

(cherry picked from commit f49b58cf97e167dca74b902fe1bf21d296495113)

1ab5e69... by Cheng-Chia Tseng

Update Chinese (Taiwan) translation

1dea334... by Fabio Tomat <email address hidden>

Update Friulian translation

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

Bump version to 3.36.1

Update NEWS.

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

extensions-app/metainfo: Point screenshots to stable branch

5c33fe4... by Jonas Ådahl

appDisplay: Don't start animation from the 'paint' signal

Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.

Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.

For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418

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

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

js: Do not set entries' ClutterText:editable property

The property influences the text's (and thus entry's) minimum width[0],
which is generally not what we want. And as we now prevent text from
being entered in non-reactive entries by other means, we can simply
drop it.

[0] https://gitlab.gnome.org/GNOME/mutter/-/blob/master/clutter/clutter/clutter-text.c#L2940

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

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

st/entry: Unset key focus when made unreactive

It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.

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