It is important that '_loadApps()' return a sorted list -- adding the
same icons at the same positions but in different orders results in
a wrong icon grid.
Add support for using a custom positioning function, and implement it
in AppDisplay. Because FolderView doesn't implement a custom sorting
function, the items are still sorted alphabetically.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
The leeways are parts of the icon that ignore incoming drag
events. This is how IconGrid and IconGridLayout treat it, and
this is how the icons should treat themselves too.
Make AppIcon ignore dragging over the left and right leeways.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
When using the NVIDIA driver, textures tend to loose their pixels when
suspending. In the past we handled this by figuring out when the NVIDIA
driver was used, and reload the background whenever we noticed we
resumed from suspend.
This shouldn't be needed anymore after
https://gitlab.gnome.org/GNOME/mutter/merge_requests/600, as it should
handle this by listening to video-memory-purged signal. Thus remove our
special handling here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1358
When using the fade animation when transitioning to the overview instead
of zoom, we fade out all window previews to fully transparent. But after
commit 751189253a removed the old _updateWindowPositions() function,
nothing resets the opacity again, so when switching from the app- to the
window picker, all previews are hidden.
Fix this by always resetting the window preview opacity after showing
or hiding the overview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
We don't animate size and position when fading, so we want all previews
to already be at their final position. However when the app picker is
opened from within the overview, window previews use the zoomed layout,
so that's the state we are then fading when leaving the overview from
the app picker.
Fix that by setting the correct state at the start of the fade transition.
(In the case of fadeToOverview(), the value should always be correct
already, but set it anyway for symmetry with fadeFromOverview())
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
In commit 9297d87775 we stopped syncing the primary view's actual
geometry at the start of the transition when doing a fade animation,
however the view animation may still be triggered by an allocation
change.
Prevent those unwanted size changes during fade by keeping track of
the fade state and explicitly skip syncing the geometry while a fade
is ongoing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
Since commit af543daf1c, we skip the overview transition when the
actual geometry hasn't been set yet. However with the new layout
manager, the only bit that still needs the separate geometry is
the transition of the view, the workspaces can do their transition
just fine.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969
When dragging the workspaces through the swipe gesture, all
workspaces must be visible. WorkspacesView's _updateVisibility()
method special-cases this and ensures that.
However, this method is only called when (1) going to the active
workspace, and (2) when the gesture ends. That means, if there
is any workspace hidden by the time a gesture starts, it is never
shown!
Call _updateVisibility() on startTouchGesture() as well.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2969https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1360
Because for most frames during a workspace switch it's not changing and
we can repaint it faster if it's cached on the GPU as a single texture.
This seems to reduce the render time for workspace switching by more
than 20%.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1356
When going straight to the app picker, we fade in the overview instead
of doing the full-blown zoom transition. In order to keep windows at
their floating position, we must apply the same to the view itself
and not transition to the overview geometry when fading.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
We don't always want to sync the geometry when entering the overview,
namely when the fade transition is used.
However we do want the correct geometry once we have entered the overview,
so that workspaces are at their place when switching from the app picker.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
Non-primary views always use their monitor's work area for their
geometry, so there's nothing to animate when leaving the overview.
The animation is already limited to the primary view when entering
the overview, so this is also more consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
It doesn't matter which animation we use to enter the overview,
we always want to start and end with the floating layout.
The simplest way to achieve that is by creating the state adjustment
with the correct value in the first place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1353
The transition was temporarily removed when switching to the new
workspace layout manager. Now everything is in place to reimplement
it with a combination of the layout manager's state adjustment and
the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
So far we've been allocating workspaces in a stack, and relied on
translation to move them to the right position. And as the position
depends on both the workspace's index and the view's viewport, some
care is needed to prevent gestures/scrolling from interfering with
layout updates.
Clean that up by properly allocating workspaces in a row or column,
and use a translation to reflect the current scroll position.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
Since the workspaces themselves stopped using it, there is little
reason for upholding the difference between "full" and "actual"
geometry.
Just base positioning/swiping on the view's allocation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
The workspace's layout manager keeps the workspace at the same ratio as
the work area, so it makes more sense to base the views' default geometry
on that as well than the monitor area we are using right now.
(It shouldn't matter much in practice, as this only affects views on
non-primary monitors where the work area usually matches the monitor area)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
We adjust the size and position of the primary view to match the workspaces
display, but views on other monitors are always set to fill their monitor.
Take that into account and create views with a fixed size and position, then
only sync the primary view to the new geometry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
WindowPreviews now contain and manage overlaid elements like close
button or title label themselves. That's generally better, but right now
the only way to disable those overlays (for example during transitions)
is to prevent any hover or focus events from getting to the preview.
Instead, add some explicit API for enabling or disabling overlay support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1345
For the windowPreview we need to ensure the style information of the
border and title is up-to-date when chromeWidths() or chromeHeights() is
called. Since the introduction of the WorkspaceLayout those functions
may be called during an allocation cycle, which means we should avoid
calling queuing relayouts inside them. Calling StWidgets ensure_style()
method will queue a relayout though in case the newly generated theme
node has a different geometry.
So avoid queueing a relayout during allocation cycles (and the warning
Clutter logs because of that) by ensuring the style of the border and
title earlier, as soon as the WindowPreview is attached to a stage.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
