Currently, there's one animation for the whole canvas. While it looks fine
with just one screen, it causes windows to move between screens when
switching workspaces. Instead, have a separate animation on each screen,
and sync their progress so that at any given time the progress "fraction"
is the same between all screens. Clip all animations to their screens so
that the windows don't leak to other screens.
If a window is placed between every screen, can end up in multiple
animations, in that case each part is still animated separately.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1213https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326
Currently, the workspace swipe transition only has one workspace in each
direction. This works until you try to do multiple swipes in quick
succession. The second swipe would continue the existing transition, which
only has 2 or 3 workspaces in it, and will hit a wall.
To prevent this, take all workspaces and arrange them into a column or row,
depending on the layout, and use that as a transition.
For the transition that happens when focusing a window on another workspace
(for example, via Alt+Tab), still use only two workspaces instead of all of
them.
Since we don't support layouts other than single rows/columns anymore,
diagonal transitions aren't supported anymore, and will be shown as
horizontal or vertical instead.
Since nw alt-tab and gesture transitions are different, don't allow to do
both at once, that is, disable swipe tracker when a programmatic transition
is going. This will also conveniently cancel a gesture transition if a
programmatic one is initiated while a gesture is in progress.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2612https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326
In future we will need to use window clones to better support multiple
monitors. To avoid having to hide every window, show wallpapers behind
the workspace transition: one per monitor.
Put the wallpaper into a separate class right away, later it will be
useful to make the animation per-monitor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326
Simplify the code a bit. The workspace group is relatively self-contained,
so split it from the general animation. Reimplement _syncStacking().
This will help a lot later, with workspace strip and multi-monitor support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326
As per design discussion, the first page is a somewhat of a special
page where we really don't want to change anything unless necessary.
Append new icons at the first available slot after the first page.
Make the placeholder icon be appended to the first available page
as well, since it's always used when dragging from folder dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
When the app folder dialog handles a drag hover, it starts a timeout
to popdown if dragging outside the "real" dialog area. However, when
dragging inside it, BaseAppView handles all drag hover events which
would disarm the popdown timeout. In cases like this, it's almost
impossible to prevent the timeout from triggering, which always pops
down the dialog.
Add a drag monitor when handling any drag hover (which only happens
when dragging outside the folder's icon grid); and eventually disarm
the popdown timeout from the monitor's motion event. Remove the drag
monitor when dragging over the folder dialog again.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
App folders are now customizable, and the way to move icons to
another page is by throwing the cursor to either the left or
the right of the grid.
However, doing that triggers the popdown timeout, wich is 600ms
as of now, which is considerably short for such interaction.
Increase this timeout to 1.5 seconds.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
Now that the DnD code is shared between AppDisplay and
FolderView, we hit an unexpected problem: FolderView is
handling drag events even when the folder dialog is hidden.
As a side effect, this spams the journal with warnings.
Only handle drag events when mapped. On unmap, disable
the view's drag monitor, and disconnect from all drag
events.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
This code will be shared with FolderView in the next commit, so
avoid duplication already and move the to-be-shared code into the
base class.
Because BaseAppView can handle vertical and horizontal orientations,
adapt the drag overshoot code to also handle horizontal overshoot.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
When redisplaying, we currently only remove and add icons, but
never adjust the position of already added icons. If the icon
position changed, it wouldn't be reflected on the icon grid.
Make sure to move already added icons.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1284
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
This is the key that will be used to store the pages and the icons in
each page. The idea is that we we store an a{sv} variant for each page.
This variant will contain <icon id> → array of properties, where we
can store arbitrary data for each icon. The expected output of this
key is:
[
{
'polari.desktop': <{ 'position': 0 }>,
'epiphany.deskop': <{ 'position': 1 }>,
},
{
'telegram.desktop': <{ 'position': 2 }>,
'builder.desktop': <{ 'position': 0 }>,
'gitg.desktop': <{ 'position': 1 }>,
}
]
The toplevel array is sorted, and pages of the grid always show in the
order they are stored.
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
The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
While GtkIconTheme does look up icons in the toplevel icons resource
path, it will only use them as ultimate fallback. That is, if the
icon theme (or the hicolor fallback) include a "keyboard" icon, it
will be used over the "keyboard-enter-symbolic" icon in the resource.
Moving the icons to appropriate subdirectories gives them higher
priority than the fallback names, and thus fixes the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2631
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
