Marco Trevisan authored May 03, 2019 and Marco Trevisan committed May 03, 2019

Dialog's subtitle or body could not be properly wrapped, while it's ellipsized
when the text's width doesn't exceed the container size.

Clutter text has an `ellipsize` property, however in dialog's subtitle and body
we have been setting the `ellipsize-mode` property to Pango.EllipsizeMode.NONE
that is not present in the underlying GObject.

Not being an error in javascript, gjs didn't warn us about this, while at the
same time the St.Label's default Pango.EllipsizeMode.END was used.

Fixes GNOME/gnome-shell#922

GNOME/gnome-shell!531


(cherry picked from commit 3121c9aa)

If an actor is pending a relayout when get_allocation_box() is called,
the method forces an allocation update. In case of StWidget, this might
then result in a style update and a consecutive invalidation of the
shadow spec.

A helper method that invalidates one of its parameters as a side effect
(and by extension its return value as well) is most unexpected, so cur-
rently _st_create_shadow_pipeline_from_actor() poses an easy trap to
callers to run into.

Remove that trap by calling get_size()/get_position() instead, which
don't have the unintended side effect - it is still a good idea to fix
callers who were running into this to not waste resources on creating
shadows that are invalidated before the next paint, but throwing un-
defined behavior at them is harsh ...

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

If the underlying X11 input driver creates multiple devices from a single
device node, we may end up picking up the wrong device. So, instead of
picking the first device based on node and bailing out if it's not a pad,
pick the first pad that has that device node, and bail out if there is
none.

GNOME/gnome-shell#10

Closes: #10

Commit f2a9467f was too eager to simplify the code, and removed
the bits that hid the section in case no VPNs are set up - add them
back to fix the visibility.

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

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

This would lead to a JS error otherwise, as we might end up
in deleting actors that have been already destructed.

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

The background code allocates a GnomeWallClock when its first created,
but neglects to drop a reference to that clock at destroy time.
The undestroyed clocks lead to a timerfd leak that eventually prevents
the shell from functioning.

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

If there are locations unknown to the libgweather version gnome-shell is
using, don't crash.

JS ERROR: TypeError: b.location is null
WorldClocksSection<._clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:141:1
WorldClocksSection<._clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:139:9

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

Guard against a malformed setting that doesn't contain a
'location' key.

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

Since commit ef1e2796 turned DashItemContainer into an StWidget,
the destroy() method overrides the ClutterActor method, which is at
the very least bad style. Instead, follow the usual pattern of using
a ::destroy handler.

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

Labels are currently destroyed from both animateOutAndDestroy()
and destroy(), which now (rightfully) triggers a gjs warning. As
the label is created unconditionally since commit 36e5ae4a,
mirror that and always release it in destroy() and hide it
elsewhere.

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

In the current code it could happen that we've menuItems and indicatorLabels
for sources that aren't anymore around, because in case a source is removed
we don't cleanup the their container objects.
Also, we should nullify InputManager's _currentSource when sources change
or it might point to some invalid data again.

So it could happen that we try to access an invalid menuitem or label
if a source change happens mentioning a source that has been deleted.

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

These end up emitting item-drag-end/window-drag-end pretty much
without checks. Given the MetaDnd object may end up emitting
::drag-leave as a result of the plugin ending its grab, this
would result on spurious emission of those events and subsequent
warnings.

For extra paranoia, the _inDrag variable has been split into
_inItemDrag/_inWindowDrag so we can't cross the streams.

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

Update NEWS.

Windows that are tiled to the left/right only use rounded corners
where they are attached to the edge, the preview should follow that.

Alessandro Bono authored Oct 26, 2017 and Florian Müllner committed Nov 02, 2017

When dragging a window between two workspaces a light effect used
to be present. The effect was lost probably during the theme revamp
in version 3.16.

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

Since 0b02f757 we track the button that should have key focus
when the dialog is opened. However when the dialog is reused, the
button may get destroyed - clear the initial focus in that case to
allow setButton() to set a new one.

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

After we receive one of the tracked signals, in case we get stuck inside
the gjs_dumpstack () call, we use an alarm to raise the previously emitted
signal, however without using SA_NODEFER, the raise inside the alarm handler
will be ignored.

To avoid to handle new signals caused by the handler calls, once we get the
first signal, we just ignore them all as they could only lead to dirty traces.

Also, cleaning up a bit the code, and disabling the shell log handler
in dump_gjs_stack_alarm_sigaction since this might lead to a new
gjs_dumpstack () request.

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

In order to debug issues triggered by JS code we might need to
see the stack of it, this is not normally visible in static stack traces,
thus we need to call gjs_dumpstack () before dying the process.

Intercepting signals SIGABRT, SIGTRAP (needed for catching fatal glib
errors) SIGFPE and SIGIOT by default, while introducing a new
'backtrace-segfaults' flag for the SHELL_DEBUG environment variable to
do the same on SIGSEGV and SIGBUS (this is a precaution to avoid that we
corrupt the stack for automatic errors trackers).

In any case after dumping the stack we raise the signal again, in order
to make the system aware of it.

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

Settings recently split Wi-Fi configuration from the Network panel,
so launch that instead.

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

Commit 28ca9606 added support for setting PopupImageMenuItem's icons
via GIcons as well as via strings. However as the check whether an object
implements the GIcon interface only works on GObjects, specifying an icon
name was broken. Fix that to actually allow both strings and GIcons.

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

We were handling being initially headless by only setting the primary
and bottom monitor if there was any primary monitor, then checking the
primary monitor reference before making calls assuming there was any
monitors.

What we didn't do was unset the primary and bottom monitor when going
headless, meaning that temporarly disconnecting a monitor while having
windows open caused an assert to be triggered due to various code paths
taking the path assuming there are valid monitors.

Unsetting both the primary and bottom monitor when going headless avoids
the code paths in the same way as they were avoided when starting
headless.

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

Update NEWS.

Meson makes it easy to define unit tests, so hook up the existing
ones.

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

We are already closing top bar menus on session mode changes, but
as this behavior makes sense for any other menus as well - dash
context menus or the background menu for instance - just generalize
the behavior.

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