While we do have some handling for removing the active menu, it has
been a no-op for years. The bit that we really care about from the
PopupMenuManager's point of view is the existing grab though. Drop
that instead of calling _closeMenu() directly; ungrabbing will still
call the method indirectly, and it will still be a no-op :-)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3022
On X11, clients can grab keyboard on pointer (for example for popup
menus), and as a result the pushModal() call when opening the overview
fails.
However when the hot corner was used to toggle the overview, we still
show the ripple animation in that case, which is confusing as the action
did not actually happen.
Fix this by only showing the ripples if the overview is animating after
calling toggle(), as that should be a reliable indication of whether
the call was successful.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3005
As backgrounds are cached, it is possible that we never emit the
'loaded' signal added in commit f386103bc1. We are relying on the
signal though, so do the same as Background and emit the signal
from an idle if the background was already loaded.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1371
Currently, the login animation can occur before the user's wallpaper has
been loaded. When this happens, we wind up displaying a solid blue
background for half a second or so before the proper background is
displayed. This looks jarring and bad. It's great that we can start
GNOME quickly, but starting up before the wallpaper is ready is *too*
quickly.
I've been meaning to fix this since 2014. Better late than never! We can
just have BackgroundManager emit a loaded signal the first time it loads
its first background, and have the startup animation code wait for that
before proceeding.
Some of this code is by Florian, who helped with promisifying. Thanks!
https://bugzilla.gnome.org/show_bug.cgi?id=734996
On Wayland, navigating menus with the keyboard would not open drop-down
menus when NumLock is enabled.
That's old issue (gnome-shell#550) that was not completely fixed with
commit 88556226 because the lock mask needs to be filtered out in
_onKeyPress() as well.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/550
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
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
