Add the necessary animations to slide in the icons in the previous/next
pages, also needing to 1) drop the viewport clipping, and 2) extend scrollview
fade effects to let see the pages in the navigated direction(s).
The animation is driven via 2 adjustments, one for each side, so they
can animate independently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
We want to show left/right side pages during navigation, also in
FolderViews. Let this scrollview use the same style than the "all
apps" one, and generalize the name a bit.
This will compress the scrollview horizontally, so there's actual
overflow space to show these pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This will be needed for fine tuning of the visible area for appGrid
navigation purposes. We most nominally can let it happen via CSS as
the size calculations happen on size allocate, so we want to avoid
triggering relayouts while adapting to the given size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This property controls whether the viewport clips the content to its own
allocation or not. This will be necessary in special modes that we want to
render past the viewport inside a scrollview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.
That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Now that the backgrounds was moved into workspaces, the fullscreen
views on secondary monitors are visually inconsistent with the
primary view, as there's no dash or search entry that reduces the
available height and allows adjacent workspaces to peek in.
Address this by adding padding above and below the view, so that
it is limited to 70% of the available height.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Right now the handling of external monitors is relatively simple, and
consists of putting either an extra workspace or a full view on the
monitor, depending on the workspaces-only-on-primary setting.
We are about to tweak the behavior on secondary monitors, prepare for
that by splitting out an intermediate actor that manages the views on
non-primaries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment views on non-primary monitors take up the entire work area,
so simply allocating the available size works. However we'll soon shrink
the views a bit to match the visuals on the primary monitor. As workspaces
keep the ratio, reducing their height will also reduce the width; override
the default allocate() to keep the extra workspace horizontally centered.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.
That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3783
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1717>
The property describes the target visibility (that is, the visibility
that will be set after the ongoing transition), and is therefore updated
at the start of the transition rather than from hideDone().
The overview gesture currently misses resetting it at the end, so it
is only updated to the correct state the next time the overview is
entered.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1726>
When adapting the check to the new versioning check, we just blindly
copied the old behavior for stable/unstable versions:
- stable releases must have matching major numbers
- unstable releases must match major and minor ("alpha", "beta", "rc")
That worked for the old even/odd scheme, but now has the absurd effect
that we consider an extension that lists "40.alpha" in its shell-version
incompatible with "40.beta", but compatible with "40.2".
At least this provides us with a good opportunity to reconsider the
behavior. While it is true that breakage is much more likely between
unstable releases, in practice extensions are either following shell
development closely or update once around the time of a stable release.
For the former, the stricter check isn't usually too useful (as the
extension releases around the same time as gnome-shell anyway).
For the latter, it's annoying that ".rc" is treated differently from
".0" and requires an update to become compatible.
The latter is also by far the more common case, so update the check
to only match on the major version regardless of whether a release
is stable or unstable.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3787
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1719>
Since commit 9980c80619, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).
To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.
The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3781
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1721>
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.
To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1707>
Since commit 0f1b566918, we use gjs' automatic getters/setters for
the shader properties. Those handle the properties on the JS and
GObject side, but they don't update the corresponding uniform,
whoops.
Revert the lightbox bits of commit 0f1b566918 to get the effect back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1712>
In the allocate() vfunc of WorkspaceLayout we use a small trick to make
the nonlinear animation paths when opening the overview less jarring:
Because a window might get smaller than its target size during the
animation, we make sure the size never drops below the final size
calculated by the layout strategy.
In the app grid the Workspace is very small though, and the size of a
window slot calculated by the layout strategy might actually be larger
than the workspaceBox. This means we might use the window slot size
instead of the workspaceBox size and end up with a window that's at the
correct position, but its size is too large.
Fix this by only applying this trick when we're animating towards or
from the state where we actually expect the workspaceBox to be larger
than the window slot, that is during the the transition from the session
to the window picker (or the other way round).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
It should be allowed to set this._spacing to 0 and thus pass 0 as
rowSpacing or colSpacing to this._adjustSpacingAndPadding(). The current
if-condition there won't add the oversize to the spacing in case 0 is
passed though.
So change that if-condition and explicitely check for null instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
