GitLab

Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.

Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.

Fixes #3833

Part-of: <!1745>

There's currently a bug that we continue showing the workspace minimap
when the number of workspaces changes back to 1 during the session (ie.
outside the overview). Fix that by also updating the workspaceThumbnails
visibility when entering the overview.

#3819

Part-of: <!1741>

The overview uses $system_bg_color as its background color, and since we
nowadays show the overview right after starting up, it makes sense to
use the same background color for the login screen.

Fixes #3812

Part-of: <!1742>

If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
#3547

I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in #3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.

Part-of: <!1727>

Previously the information which commit failed a commit message check
was hidden in parts of the report that don't show up in gitlab's UI.

Part-of: <!1740>

We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.

To fix that, update the indicator on workspace changes as well.

Part-of: <!1716>

New workspaces are added in two steps, first the minimap expands to make
room for the new thumbnail, then the thumbnail animates in. However we
currently don't queue a state update after the first step, so the second
one only happens after one is queued by some other event (like a workspace
switch).

#3748

Part-of: <!1716>

Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.

This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.

Part-of: <!1713>

It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.

This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.

Part-of: <!1713>

This gets our time spent in vfunc_allocate() down again by ~0.1 ms from
1.4 ms to 1.3 ms.

Part-of: <!1713>

vfunc_allocate() is a hot path, and we don't want to do expensive stuff
there, so avoid updating the pages, which seems unnecessary anyway.

Part-of: <!1713>

Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.

Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.

Part-of: <!1713>

We need to access the visible children of a page in inside
vfunc_allocate(), and since getting those children is quite slow (it
involves iterating over all the children of the actor) let's avoid that
and cache the array instead.

This reduces average time spent in vfunc_allocate() of the iconGrid from
1.6 ms down to 1.4 ms.

Part-of: <!1713>

We call this._getChildrenMaxSize() from the allocate() vfunc of
IconGridLayout. Since the function is quite expensive, it slows the
layout process down a lot, so instead of re-calculating it on every
relayout, cache the max size of children.

This makes the average time spent in vfunc_allocate() of the iconGrid go
down from 2.3 ms to 1.6 ms.

Part-of: <!1713>

Part-of: <!1738>

Part-of: <!1246>

Instead of always aligning window previews vertically at the bottom of
their row, only do that if we have multiple rows. If there's only a
single row of windows, align every window vertically centered.

This is a very small step towards the new layout for window previews in
the overview, but since the release of 40 is getting nearer and nearer,
changing more is not feasible anymore.

#3634

Part-of: <!1737>

Use a bit less spacing between the workspaces in the window picker, this
uses more of the available space and makes it easy to take a peek at
adjacent workspaces.

Part-of: <!1702>

To ensure the workspace thumbnails are vertically closer to the window
picker than to the search, scale down the wallpapers by a fixed number
of pixels. Using 24 px for this means we'll take of 12 px at the top and
12 px at the bottom of the wallpaper, that's a better strategy than
always scaling it by a fixed factor since it doesn't change with the
monitor size.

Part-of: <!1702>

Use a bit less margin at the top and add some margin at the bottom of
the search entry. This should ensure the search entry is closer to the
panel than to the workspaces and avoid associating the workspace
thumbnails with the search instead of the window picker.

Part-of: <!1702>

The Dash currently has a horizontal margin and a top margin applied. The
horizontal margin isn't necessary since there already is a horizontal
padding applied, and the top margin is a bit large, since the
ControlsLayout enforces a spacing between the different containers
already, so slightly decrease the margin-top here.

Part-of: <!1702>

In the overview we want to make sure window previews are shown as large
as possible, so make the spacings a bit less excessive and only use a
16px spacing.

Part-of: <!1702>

The back → transparent transition gives it a very bad look when
booting and running the startup animation.

Use the same transition duration hack to ensure that the panel
starts completely transparent.

Part-of: <!1678>

There's this little hack that we do to match the panel transition from
transparent to black with leaving the overview via swipe down. The only
problem is that, while the duration of the panel transition itself is
matches, the corners don't, and they get out of sync.

This isn't very noticeable with the swipe gesture, but it'll be much
more prominent when booting straight into the overview.

Bind the 'style' property of the panel to the corners', so that the
transition duration hack applies to all of them.

Part-of: <!1678>

The new startup animation consists of rising the Dash from the bottom,
falling the search entry from the ceiling, and going from HIDDEN to
WINDOW_PICKER with an opacity applied.

One little trick from IconGridLayout was added to ControlsManagerLayout,
which is a promises-based wait for allocation. This is required to make
sure that the transformed position of the search entry is valid, which
is only the case right after an allocation.

This animation also ensures that the overview is shown right on startup.

For session modes that do not have an overview, continue using the same
fade + scale animation.

Part-of: <!1678>

It'll be used by the next commit.

Part-of: <!1678>

We want to avoid updating the input region on startup, since it incurs
in roundtrips to the X server, but not workspaces struts, since they
affect the visible clip of wallpapers in the workspace. Since next
commits will make the overview be the after-boot screen, we really
don't want the wallpaper to be clipped wrongly.

Allow updating regions while starting up, but only workspace struts.
Make sure input is not updated by accounting for 'this._startingUp'
on 'wantsInputRegion'.

Part-of: <!1678>

This is an X11-specific routine, and building the list of input region rects
on Wayland is a waste, since it incurs in many trampolines only to throw them
in the trash.

Don't build input region rects on Wayland. By modifying the 'wantsInputRegion'
variable, it also skips actors that only update input, which is another small
optimization for Wayland.

Part-of: <!1678>

LayoutManager doesn't update struts when there's any modal running. Turns
out, the Overview itself is a modal. That, and the fact that the Overview
will be the startup state, prevents the workarea to be updated.

Allow updating struts when there's no other modal than the Overview.

Part-of: <!1678>

Be consistent and use the same wifi signal strength thresholds that are
used by Settings to ensure that the signal strengths look the same in
Settings and gnome-shell.

See https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/panels/netwo>
for the	values used in Control Center.

Fixes #217

Part-of: <!1432>

Launching applications on a particular workspace works through
launch contexts and startup notifications. While this is no
longer required by a launcher/WM split, in theory this allows
us to reliably identify the correct window to apply startup
properties to.

However in practice we fail more often than not: Missing support in
toolkits, differences between display protocols, D-Bus activation
and single-instance applications all provide their own pitfalls.

So instead, take advantage of the fact that launcher and WM live in
the same process, and go with the unsophisticated approach: Just
remember the last workspace that was requested when launching an
app, then move the next window that is associated with the app to
that workspace.

This will break X11 applications that set an initial workspace, but
that's legacy functionality anyway (given that there's no wayland
protocol for that functionality), and seems a price worth paying
for making launching apps on workspaces more reliable.

Part-of: <!1316>

When the setting is false, we apply anyway depending on the adjustment
value. Look for the right value corresponding to that side as per the
locale.

Part-of: <!1630>

Let the goToPage call afterwards to take precedence, instead
of resetting the adjustment (thus the view) on the side.

This resulted in strange state when the last page contains
a single icon, and it is dragged. The last page being emptied
triggers a pages-changed signal, which half resets the view
to the first page while DnD is ongoing.

Letting goToPage do its business means we neatly clamp to the
closest page to currentPage, the last page in that case.

Part-of: <!1630>

When clicking on the page hints, the hint rectangles being visible
in place and not moving together with the page is a bit too
distracting.

Since the page hints are not part of the iconGrid hierarchy and
we have just 2 general ones for prev/next page (i.e. no page
associated), do this sliding via some smoke and mirrors: We don't
slide the page hints, but a parent container for both of them, and
we also control opacity so that the container is fully transparent
mid-page. At the point it is transparent, the container can be
snapped to the other side of the page, and faded back in as it
slides together with it, so it always looks like it goes away and
comes from the right sides.

Part-of: <!1630>

Depending on the available horizontal space, we may want to manipulate
the icon grid and scroll view spacing to result in an optimal layout
that has space left to preview prev/next pages.

The main change here is that, when adapting to the available size, the
space given to a page does not necessarily match the available space,
as we need to be able to show more than one page at a time.

With this decoupling of available and page sizes in place, we now know
how much space there is available in order to extend the padding between
pages, or the fade effect applied to the previewed pages.

Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more
on the StScrollView::content-padding property.

All put together, gives us proper space management from ultra-wide
displays, to display ratios that are close to the optimal grid ratio.

Part-of: <!1630>