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 https://gitlab.gnome.org/GNOME/gnome-shell/issues/922https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/531
(cherry picked from commit 3121c9aa29)
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.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/10Closes: #10
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
Since commit ef1e27966d 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 36e5ae4a25,
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
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 0b02f757f8 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
Commit 28ca96064b 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
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
Commit 1c7a3ee61b broke setting the initial key focus for default
buttons added via addButton(). Fix this by allowing the dialog class
to provide a different default widget to ModalDialog than the entire
dialog itself.
https://bugzilla.gnome.org/show_bug.cgi?id=788282
We don't use different hover- and focus indications for window previews,
so using keyboard navigation after hovering a clone often has surprising
results when the previous focus window wasn't the selected one. Address
this by simply moving the keyboard focus with the highlight.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
By default the focus chain uses the same order as the list returned
by clutter_actor_get_children(), which corresponds to the z-order.
This doesn't work well in the window picker, where clones follow
the stacking of windows to ensure a correct overview transition,
but previews are laid out purely based on space efficiency. As
a result, the order in which window previews are navigated when
tabbing around is essentially random. Fix this by providing a
focus chain implementation that is based on the visual layout
of the previews rather than the stacking.
https://bugzilla.gnome.org/show_bug.cgi?id=786546
Don't assume there will always be a primary (logical) monitor, or any
(logical) monitor at all. This includes not allocating / layouting /
styling correctly when being headless.
The initial background loading will also be delayed until there are any
(logical) monitors connected.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
