We set the expand-fraction property of the workspace thumbnails on changes
to their should-show property. The should-show property defaults to true, and
the expand-fraction property defaults to 1. The should-show property gets
updated in the constructor of the ThumbnailsBox though, and it might become
false (that is the case when starting up the shell) during construction.
In this case we're not yet listening to "notify::should-show" in the
ControlsManager, and therefore forget to update the expand-fraction
accordingly. Fix that and ensure the expandFraction is always set to the value
we expect after hiding or showing the thumbnails (we call _updateThumbnailsBox()
from _update(), which we call in the constructor).
This should be the proper fix for the problem that 9bf550da8 (which caused
the workspace thumbnails to never show) originally tried to fix.
Fixes: 9bf550da88 ("overviewControls: Set expandFraction for ws thumbnails to 0 when hidden")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7668
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3323>
If the idle callback is not explicitly removed when the notification is
destroyed, it may be invoked after destruction, and try to modify the
notification after it’s been freed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3352>
If no child setup is provided then all the shell extensions that use
GLib.spawn_async should actually use the shell spawning utils since we
are supposed to always restore the default nofile rlimit on launched
children.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
Using child setup functions is unsafe in gjs code so let's warn if this
happens so that extensions using a similar codepath are warned.
This could be also part of gjs, but we provide a shell override since we
have alternatives to log about.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
A feature that works for server side decorated windows only that
only adds slightly more convenience over the regular "move" action that
is still there.
Keeping it around would complicate some cleanups in upstream Mutter
so just drop it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3332>
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
We currently compute the target scale from the allocated height,
which means that it only becomes available after thumbnails have
been allocated at least once at their expanded height.
As the minimap is initially hidden, this only happens after it is
expanded for the first time, which means the corresponding transition
is not animated.
In order to allow for a fix, compute the target height ourselves
to allow the scale computation to work independently from the
expand factor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3331>
We no longer provide a portal implementation, so there's no need
for owning the name. Right now only the gnome portal consumes
the API, and that accesses it under "org.gnome.Shell".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3326>
We use the pagePadding to adjust for the large indicators that we add on the
left and right of the appGrid.
While the original padding needs to be applied to the padding for the
indicators (as it was in super.vfunc_style_changed already), there's no
reason to add an extra row and column spacing to the pagePadding on all
sides, so remove that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
We multiply the spacing around the workspace thumbnails with the
expandFraction so that it grows with the animation to show/hide them. We
shouldn't factor in the extra spacing to accomodate for the thumbnails in
case they're hidden though, so make sure expandFraction is set to 0 after
the thumbnails got hidden.
This fixes the spacing when a user never uses workspaces (and the workspace
thumbnails are never shown), and also the first transition from
hidden->shown for the thumbnails, which currently starts at 100% scale (ie.
pops into existence).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
With a previous commit we've made the overall dynamic spacing dynamic, but
the spacing is now a bit much when it comes to the space between search and
workspaces minimap, just as workspaces minimap and large workspaces.
The minimap should somewhat "squeeze into the empty space" here, so
reduce the spacings above and below it a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
The naming of the appGridBox is quite confusing, as it actually
describes the box of the workspaces strip, but in the appGrid state of
the overview. Change that name and call it workspacesBox instead, which
seems to make more sense here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
After the recent notification changes, the title may still be null
when the source is originally added. Handle that case and make sure
we pick up later title changes by setting up a property binding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
Adding a notification clearly constitutes a count change, but
the notify call was accidentally dropped during the overhaul
of the notification API.
Fixes: 34f05b075b ("messageTray: Let the tray decide whether to show a
banner")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
The fallback path broke when we removed support for window icons.
Nowadays we track all windows, and as a result should always have an
associated app (although not necessarily backed by a .desktop file),
so this shouldn't make a difference in practice. Not to mention that
external docks (like cairo-dock) are extremely rare themselves now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3295>
Override redirect windows manage their own positioning and size alone
and are always sticky, so we're not covering them either with the
animation MonitorsGroup, and thus there's no need to clone them or we'd
end up having two windows painted.
This was causing the shell tray icon window actors (that have no opacity
by default but that are override redirect) to show up during the
animation as their clone animation is not 0.
The other option would be hide them during the animation phase, but
there's no need for this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3285>
'icon-missing' is not an actual icon name. It somewhat works
because an invalid icon name will fallback to the correct
'image-missing', however for apps the generic app icon is
a better fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3248>
Setting `useBodyMarkup` to `true` fails with:
JS ERROR: TypeError: this.setBody is not a function
set useBodyMarkup@resource:///org/gnome/shell/ui/messageList.js:585:14
Fixes: f0e863f529 "messageList: Use GObject properties for Message"
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3232>
The fallback for creating models is to try the next one in case the current
one can not be created, until we fall all the way back to the US layout.
Obviously we shouldn't fall back in case creating the model actually worked,
so break out of the loop and then use the new model.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3230>
