After an extension is installed, run `glib-compile-schemas` on its
`schemas` directory, if it exists.
This should avoid any endianess-related issues for extensions when
running GNOME Shell on varying architectures.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
This is something that will be used in other places outside the
background code, so let's just define it globally without having to care
about the importing order.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
We include a private hidden .desktop file for evolution's calendar
component, so that we can explicitly open that component when
evolution is configured as the default calendar application.
That's because the evolution developers didn't want to ship
additional .desktop files at the time, but they have since
then included a desktop action that can be used for the same
purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2479>
Switching between the app grid and the window picker in the overview via
gestures results in _gestureEnd() getting called with endProgress !== 0
in both cases, which leads to it calling _showDone(). This then
unconditionally changes the state to SHOWN, which in this situation is
already the current state. Since the previous commit this results in a
warning, so check if we are already in the SHOWN state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
There have been several bugs in the past that caused invalid transitions
of the `shown` state, such as going from `showing` to `showing`. These
cause consecutive emissions of the `showing` signal, which can confuse
other classes such as the search controller which connects to the stage
`key-press-event` on showing and disconnects again on `hiding`. Having
two consecutive `showing` signals will cause it to connect twice, and
only disconnect once when hiding the overview again. This will lead to
key presses getting repeated in the search until the session is
restarted. Because there is no obvious connection to how and when this
issue got triggered, this now adds some validation code that only allows
valid transitions and throws an error otherwise so we get a backtrace of
the code actually causing the problem.
This does not fix the issue(s) causing the invalid state transitions, it
only adds a way of tracking them down.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
Sandboxed apps that run without a window are detected by the new
background monitoring service, introduced by xdg-desktop-portal.
We have an opportunity to improve the predictability of the desktop
and ensure that application state in transparently reported to users
by showing these apps, and allowing them to closed.
Add a new background apps menu to the quick settings, that is always
added at the bottom of the popover, and has a slightly custom, flat
style applied to it.
Show background-running apps in this menu, and allow closing them
by first attempting to execute the 'quit' action through D-Bus, and
if that fails, sending SIGKILL to the process.
See https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/191
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2624>
Since commit a1d650ce27, window title changes are listened for in the
ShellWindowTracker in order to emit ::tracked-windows-changed when
there are window title changes.
The rest of the things that happen in between (removing the window
from a ShellApp, possibly have it destroyed, and possibly creating a
new ShellApp to re-insert the window) are superfluous and even result
in the altTab switcher popup ending up confused about the applications
available.
Only emit the signal so changes can be followed on D-Bus, but avoid
the ShellApp fiddling otherwise.
Fixes: a1d650ce27 - window-tracker: Emit 'tracked-windows-changed' on title changes
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6385
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2634>
Menu toggles are currently regular toggles with an additional
arrow button. This allows for a simpler implementation, but
has downsides with regards to keyboard navigation and hover
feedback.
To make it more obvious that the two parts of the menu toggle
perform different actions, change the overall structure of the
toggle to *contain* a regular toggle and the menu button.
That way each element uses its own hover effect, and shows up
in the keynav focus chain.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5964
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2632>
