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
The script was used by a distcheck hook to check for files that are
in git, but not the distributed tarball. We dropped autotools support,
so the script is no longer used - in fact, it isn't useful anymore,
as `ninja dist` generates tarballs from git itself rather than from
a separately maintained list of files ...
Similar to what it's done in _shell_app_add_window(), rely on calling
shell_app_sync_running_state() when removing windows too, to avoid
transitioning to STOPPED while it's still in the STARTING state.
This makes the logic compliant with the startup notification spec and
prevents stopping an application too early if it has a splash screen
that has been closed before the application's main window is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=787905
On the screen shield, the only possible interaction is lifting the
shield. The on-screen-keyboard is not useful for that, and the drag
gesture from the bottom may in fact conflict with dragging up the
shield, so disable it.
https://bugzilla.gnome.org/show_bug.cgi?id=788339
As notification icons now align with the title, it makes sense for
them to follow the text size in case a text-scaling-factor other
than 1 is applied.
https://bugzilla.gnome.org/show_bug.cgi?id=788265
Not doing this will throw a backtrace when running on headless mode and
trying to show a notification, due to Main.layoutManager.primaryMonitor
being undefined, so it's better to return early.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When making any D-Bus call through the GDBus' proxy wrapper with an
invalid D-Bus object path, gnome-shell hangs.
Supposedly FdoApplicationProxy constructor should validate the passed
D-Bus object path and throw an error if the path is invalid. Since it
does not do that, we work it around by making sure that the deduced
D-Bus object path is valid or throw an exception if the path is not.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Some application IDs contain hyphens, which are not allowed in D-Bus object
paths, so we need to update the translation by converting them to something
that's a valid object path. This is consistent with what GApplication does.
https://bugzilla.gnome.org/show_bug.cgi?id=787902
Meson now warns when specifying the rpath in linker flags instead
of using the newly added build_rpath option - now that we already
depend on the latest release, there's no reason anyway to not use
the nicer syntax.
https://bugzilla.gnome.org/show_bug.cgi?id=786343
When creating a shadow for a ClutterTexture, we currently use the
underlying CoglTexture directly instead of rendering the actor to
an offscreen buffer. This assumes that the CoglTexture is directly
suitable as shadow source, which isn't necessarily the case - it
may have a very different size than what is shown and scaled up or
down by the hardware. In that case we end up with a scaled shadow
texture as well, which messes up the desired blur effect - the
result will be too light when scaling up, or too sharp when scaling
down. To fix this, only take the shortcut when a ClutterTexture's
underlying texture has the correct size and fall back to offscreen
rendering otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=788039
Commit 289f982949 broke all remote providers when adding support for
non-auto-started search providers: Whether the provider should be
auto-started needs to be known in the constructor, so setting the
property on the constructed object doesn't work.
https://bugzilla.gnome.org/show_bug.cgi?id=787986
Ensure that key-above-tab for selecting window application is consistent
with the down key.
After focus an application in the switcher:
- if you press down, the window thumbnails are previewed, and first element
is selected
- if you press key-above-tab, the window thumbnails are previewed, however
the second element is directly selected.
Make both interactions always select the first element.
https://bugzilla.gnome.org/show_bug.cgi?id=786009
