Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4720
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2014>
(cherry picked from commit bc32a52108)
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
(cherry picked from commit cc5cc0d653)
If the preedit is in invisible state, the last preedit string that
was sent around is already null, so there is no need to clear the preedit
in that case.
(Cherry-picked from commit 0177560952)
commit 8721c5db37 made StPasswordEntry
honor the 'disable-show-password' setting.
Unfortunately, it introduced a lifecycle bug where the signal handler
for noticing setting changes can out live the entry itself.
This commit fixes the problem by using g_signal_connect_object
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2004>
This job "needs" the build job and thus gets its artifacts, but
it will not inherit the environment where we already installed
Mutter in /usr. This apparently broke once there was a more
recent mutter-clutter .pc file to look up.
Install Mutter in /usr again in this job, so the new build for
coverity finds all dependencies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1979>
If a user hits escape twice really fast when coming back to
their machine to unlock it, they made end up getting presented
with a non-functional unlock screen that doesn't show their
user icon and doesn't ask for a password.
This is because showPrompt assumes that if an auth prompt already
exists, it's ready to go. That may not be true, if it's in the
process of getting torn down at the time because it's in the middle
of a cancel animation.
This commit solves the problem by ensuring the auth prompt is always
in a fresh reset state before showing it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
If the the unlock dialog gets finished before an auth dialog is
created, the code currently creates one just to tell it to finish.
This commit changes the code to skip creating the auth dialog in
that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
Commit dd2cd6286c restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1990>
Icons that are changed while an actor is not mapped may not have a theme
node associated with, and thus we'd end up not updating them at all.
In fact we return early in st_update_icon(), and this was not an issue
until commit 0b1dfbf6f3, because we'd end up to update the icon anyways
once the style was changed (and so with a valid theme node), but since
such change we might not updating the icon if no theme detail changed.
To prevent this, add a flag to require an icon update when the theme
changed, if no successfully update happened earlier.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4568
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1983>
St's theme test now requires the libmutter-test library, which is only
built when tests are enabled. Instead of mandating a particular build
configuration in mutter, add a corresponding option in gnome-shell as
well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1975>
We currently just call sassc, but don't check its return value. That
means as long as sassc is available, the script (and therefore the
newly added dist CI job) will succeed.
Make sure we fail on failure.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1974>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1968>
