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
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
Switch to the new WorkspaceLayout layout manager to allocate the window
clones of the overview properly using Clutters layouting mechanisms.
Since we now no longer make use of the fullGeometry, we can remove the
setFullGeometry() function from the Workspace class. Also we can stop
setting the actualGeometry on the Workspaces and WorkspaceViews and
instead just set the fixed position and size of the views to their
full or actual geometry. This also has the benefit that we no longer
have to set a custom clip, but can simply enable clip_to_allocation.
The geometry needs to be set inside a BEFORE_REDRAW later because
_updateWorkspacesActualGeometry() is called from a notify::allocation
handler.
This isn't doing any animations when showing/hiding the overview yet,
we'll add that in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
Add a new ClutterLayoutManager for layouting the workspaces of the
overview, WorkspaceLayout.
This layout manager integrates the existing LayoutStrategies used to
layout the window clones of the overview and supports freezing the
layout, animating between layout changes and adjusting the spacing for
the width and height of the window chrome. It also adds support for a
layout of the windows that looks the same as the actual workspace,
transitioning between that layout and the LayoutStrategy can be done by
setting the value of an StAdjustment, available using the
stateAdjustment getter function.
This will replace the current static-positioning based layouting of the
window clones in the next commit.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
We're going to use fixed position for positioning workspaces when
they're allocated by their own layout manager, using those positions to
scroll between different workspaces interferes with that, so do that
using translations instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1305
In portrait orientation, we set the height to the preferred height
for the monitor width (or, if smaller, a third o the screen height).
However as the forWidth currently doesn't make a difference, the height
is effectively controlled by the natural height of the keys - which is
rather small.
Address this by making AspectContainer request an appropriate preferred
size based on the fixed ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2349
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
The blur effect needs to take the scale-factor into account, so we
listen for scale changes. However we set up the signal handler when
creating a background, which is repeated for each monitor, and every
time the monitor configuration changes. But we only disconnect the
last handler that was connected, and only when we are destroyed,
not when recreating backgrounds.
Fix this by splitting out updating the effect parameters to a separate
method that iterates over all backgrounds, so we can simply set up the
handler from the constructor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1341
The arrow of the removed app was still left in the list with the
visibility of the arrow still depending on the original list order. This
could either lead to apps with just one window now suddenly having a
down arrow or apps with multiple windows not having one. If the last
window in the list had a down arrow, it would have been displayed
outside the window switcher.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2935https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1340
As usually with GObject setters, we should check whether the property
actually changed before setting the value and notifying the property. So
check whether the title or description text actually changed before
setting it.
This fixes a bug which makes the title flicker and change its size,
because when updating the title we remove the "leightweight" css class
and reapply it inside a later, which makes the title appear larger for
one frame.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1336
Noticed while working on customizable folders. Calling GrabHelper.ungrab()
ends up calling FolderDialog.popdown(), but at this point the '_isOpen'
field isn't updated yet, so we end up calling popdown() twice.
Update the '_isOpen' field before ungrabbing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Overview has signals to notify about starting, cancelling, and
finishing icon drags, but none of these signals pass the dragged
item to the callbacks.
Pass the dragged items to the 'item-drag-*' overview signals.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1332
Commit c7e597cf72 tried to improve the slide animations when entering
the overview by using the same time as the overall overview animation,
but in fact broke the animation most of the times.
That is because the Overview imports OverviewControls before defining
the ANIMATION_TIME variable, so any javascript code that is evaluated
during that import will see the value as "undefined" (which is converted
to 0 for the animation).
Fix this by moving the ANIMATION_TIME variable before the imports instead
of the usual placement.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1331
When you tap Super and see the sidebars and windows slide, it looks more
cohesive if those animations complete at the same time.
Previously there were 0.09 seconds difference between the two animations
which was enough to make it look slightly buggy. Now it doesn't.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1289
We now found the underlying bug: The ControlsManager (which causes the
bad call to `_updateWorkspacesFullGeometry()`) is getting (re-)allocated
while we add the view to the overviewGroup actor because the
overviewGroup is already visible and the view is immediately getting
mapped by `clutter_actor_add_child_internal()`. That causes a
resource-scale calculation and that indirectly causes a call to
`_clutter_stage_maybe_relayout()` (explained more detailed in the last
commit).
So now that we got rid of the immediate relayout happening when mapping
the view, we can revert this fix.
This reverts commit 6cc19ee6f0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1315
When the bounding box size is 0 during allocation (which happens right
after creating a window for example), we're doing a division by zero and
end up with a NaN scale. This ends up making the childBox NaN, which
triggers an error in Clutters allocation machinery.
So fix that and fall back to a scale of 1 in case the bounding box is
empty.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1320
The current microphone indicator only indicates if the microphone is in
use. Users might be also interested if their microphone is recording
or is muted, this commit enables that without opening the pop-up
menu. The microphone icon changes itself, depending on the sensitivity
of the microphone. It behaves similar to the already existing volume
indicator.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2902
In the past, the icon grid would update the number of pages
during the call to adaptToSize(). However, after the new grid
layout landed, the number of pages is updated by the time an
item is added or removed.
Instead of comparing the old and new number of pages in the
icon grid, compare the pages shown by the indicator, and the
grid pages.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Now that we don't have the Frequent tab anymore, and subsequently
the buttons to switch tabs, the app grid fill all the way to the
bottom, leaving no room for drag overshoot.
Add a 20px (i.e. OVERSHOOT_THRESHOLD) area at the bottom of the
grid where dragging actually scrolls to the next page.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The two BaseAppView subclasses now share a lot in terms of
widgetry: they both have a scroll view, pagination dots, swipe
management, etc.
Move this shared code into BaseAppView. Notice, however, that
BaseAppView only creates the widgetry, but it doesn't add them
to any specific layout. FolderView arranges the widgetry in a
vertical box, while AppDisplay arranges it in a ShellStack.
Add a new 'orientation' parameter to BaseAppView and use it
to determine the orientation of the pagination dots, the swipe
tracker direction, and the scroll event handling.
It is worth noticing that the scroll event is a bit more
sophisticated now: when the orientation is horizontal, it
handles all directions since mice wheels usually only generate
up/down events.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When FolderIcon is destroyed, it destroyed the FolderView and, if
there's a folder dialog present, it destroys the dialog as well.
Turns out, the folder dialog adds the icon's FolderView to itself.
The view becomes part of the dialog's actor tree. When the dialog
is destroyed, it also tries to destroy the view - but the folder
view was already destroyed by FolderIcon!
Fix that by letting the dialog destroy the folder view if it exists,
otherwise destroy the folder view directly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
Add app icons to the exact page and position they're located
instead of always appending. This will be useful later when
custom icon positions are in place.
For now, it assumes pages are always filled, which is true,
but this will also change with custom icon positions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
AppDisplay currently adds all icons, and hides the ones inside
a folder. Change that to only add the icons that are not inside
folders. Adding an icon to a folder removes the icon from the
main grid.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
When filtering out the app icons, AppDisplay calls FolderIcon.getAppIds(),
which then calls FolderView.getAllItems(). This last function reads the
already added app icons inside the given folder, and return their app ids.
So far, so good.
When the GSettings backing a folder changes, FolderIcon emits 'apps-changed'
to notify AppDisplay that the folder changed.
Cool.
When AppDisplay receives this signal, it first recreates its own icons, then
updates the folders, and finally hides the icons that are inside folders.
This series of events is unfortunate. Future patches will need the folder
to be updated *before* AppDisplay updates its own icons.
Update folder icons before chaining up to BaseAppView._redisplay().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The icon grid is always paginated, so the app grid code doesn't need
to behave differently in the FolderView and AppDisplay.
Move the keyboard handling to IconGrid itself, and remove the now dead
code from AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
The new icon grid layout operates based on rows and columns, and
doesn't try to dynamically adapt it to fit to the container. In
this case, it is better to have a pre-defined set of well-known,
well-tested rows and columns, and switch between them based on
the aspect ratio of the screen.
Introduce a set of modes to the icon grid, and select the mode
that is closest to the aspect ratio.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
