The app grid itself now is horizontal, and is displayed beneath
workspaces, above the dash. This makes the indicator animations
out of place, as they're not coming from the edge anymore.
Use PageIndicators for both FolderView and AppDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1629>
The new window preview overlay requires getting the app icon for a
window from the window tracker when it gets initialized. The window
tracker listens for the same 'window-added' signal on the MetaWorkspace
that the gnome-shell Workspace listens for to add the window preview.
The window tracker however reconnects all its signal handlers whenever
the number of workspaces changes, which means that its signal handlers
get called after the ones in Workspace ones. So by the time the
'window-added' handler in Workspace is called, the window tracker does
not have an app associated with the window.
To fix this ensure that all window related signal handlers in Workspace
are run after the ones in the window tracker.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3656
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1625>
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/1213
Part-of: <https://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/2612
Part-of: <https://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.
Part-of: <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.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1326>
We always request a natural width based on the maximum thumbnail scale,
but may very well use a smaller scale when allocating. This currently
results in thumbnails being off center, fix this by distributing any
extra space evenly before allocating thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1620>
Accessing GObject properties from JS has proven to be quite slow because
of the JS->C->JS roundtrip involved. With the WindowPreview this
actually has an impact since we're accessing those properties very often
while creating new layouts.
So cache the boundingBox and the windowCenter properties of the
WindowPreview using a this._cachedBoundingBox JS object. This might
speed up opening the overview with lots of open windows significantly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Make computeScaleAndSpace() return an array including scale and space so
we no longer have to access the layout object from outside.
With this we also no longer need to set layout.space, since only the
scale property is needed in computeWindowSlots().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Start cleaning up the whole mess around the layout object a bit and
return a new object in the LayoutStrategies computeLayout()
implementation. This object is supposed to be opaque to the API user and
will only be passed to the layout strategy.
For now, keep setting a few things on that object from outside, we'll
clean that up later.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Only keep computeLayout, computeWindowSlots, computeScaleAndSpace and
the contructor in the superclass, the rest is actually layout specific
and won't apply anymore when we introduce the new vertical layout
strategy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1617>
Move the background to the Workspace class by introducing a new container
called WorkspaceBackground, which handles clipping the background to the
workarea.
Move the click action from WorkspaceDisplay into each workspace.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1599>
When the original animation was implemented, workspaces would only
ever be added at the end. We therefore got away with not having a
separate EXPANDING stage corresponding to the existing COLLAPSING
one when animating out.
Since support for creating in-between workspaces via DND was added,
this is no longer the case. And now that the thumbnails are centered,
the jump is quite noticeable.
Address this by adding new transitional states, so that we can
expand new thumbnails before scaling them in.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1609>
Make the slide property control the workspace scale, so that new workspaces
scale up, and destroyed workspaces scale down. The scale is done horizontally,
and only slightly vertically, as per design direction.
Rework the state tracking mechanism to remove the COLLAPSING state, since there's
no split between sliding out and collapsing anymore. Also remove the corresponding
'collapse-fraction' property from WorkspaceThumbnail.
Make ThumbnailsBox.vfunc_get_preferred_width() consider the slide-position property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
There are situations where MetaWorkspaceManager and ThumbnailsBox disagree
on the number of workspaces, for example when animating them out. It's more
important to follow the visible number of workspaces while they're updated.
Make vfunc_get_preferred_width() and vfunc_get_preferred_height() use the
current number of workspace thumbnails to calculate their sizes, instead of
MetaWorkspaceManager's n-thumbnails property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
ThumbnailsBox currently allocates each workspace thumbnail using their
porthole size, and scales them down using scale-x and scale-y. This is
slightly problematic since it doesn't allow for properly styling these
thumbnails through CSS.
Rework ThumbnailsBox to allocate workspace thumbnails at their actual
sizes, and scale down the '_contents' actor inside WorkspaceThumbnail.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Allocate workspace thumbnails horizontally. This requires introducing code
to handle the RTL direction. Do a small rewrite of the DnD hover method to
be simultaneously simpler and easier to follow, and work correctly on RTL.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
This is now all centralized in the apps page, so move the workspaces
thumbnails to ViewSelector's apps page. This allows us to remove
all the slider controls too, since they're now unused.
The transition between showing the workspaces, and the app grid, is
based on the most recent mockups: scale and move it down, and fade it
out.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Now that there's only a ACTIVITIES and a SEARCH page, the old method of handling
keyboard tabbing (extra parameters to ViewSelector._addPage()) limits what we can
do.
Manually set up the Ctrl+Alt+Tab support for each element.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Add them both in a StBoxLayout subclass with a vertical layout. This
new ActivitiesContainer class already contains an adjustment controlling
the transition between workspaces and app grid states, and althought it
is internal to it, it'll be easy to integrate with gestures in the
future.
Notice that AppDisplay is added before WorkspacesDisplay. That's because
we want the paint order to paint WorkspacesDisplay on top of AppDisplay.
Switch the ViewsPage enum to call this page ACTIVITIES, and adjust the
only caller in OverviewControls to it. At last, rename '_appsPage' to
'_activitiesPage' to also reflect the name change.
The usefulness of organizing this code in pages is lost here, but this
is a transitional state, and pages will be removed in future changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1593>
Only the area used by favorite apps can be used as drop targets, it
is not possible to add new favorites between the running apps at the
end. While that behavior makes sense, it is currently impossible to
distinguish the two areas with confusing results.
Address this by adding a visual separator between favorites and
running apps.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1606>
WokspacesDisplay simply remaps the scroll direction into the next
workspace, but that doesn't account for the new horizontal layout.
Scroll horizontally on horizontal layouts when scroll direction is
on the vertical axis.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1603>
The scroll adjustment's upper value corresponds to the number of
workspaces, not to the last workspace index. We want the latter
when mirroring the layout in RTL locales, so subtract 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1598>
Now that apps either appear in the dash or the app grid, it makes
sense to allow DND between the two components to add and remove
favorites.
Currently this only works for adding items to the dash, update the
app grid code to also accept drops from the dash.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1594>
We use a custom actor to make sure that the show-apps button remains
visible even when there's not enough space to show all icons.
We can achieve the same result with much less code, by using a custom
BoxLayout layout manager for the icons to override the minimum width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1592>
With the transparent top bar in the overview, constraining to the
primary monitor's workarea causes the (now visible) area beneath
the top bar to not have the darker background, which causes a visual
discontinuity in the layout.
Don't constrain to the primary monitor workarea.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1590>
The code previously was using CSS to define row/column spacing and
padding which was combined with a subicon size computed in code relative
to the requested icon size.
In smaller icon sizes it was possible for the CSS spacing+padding + the
size of the two subicons to exceed the requested icon size. This then
would lead to the label being pushed down for app folders compared to
other icons.
Another more severe issue caused by this would happen if the first item
in an icon grid was an app folder. Then the calculation for the maximum
allowed icon size could be off, leading to all icons in the grid
becoming smaller than actually necessary.
This commit changes this to use homogeneous row and column layouts to
evenly distribute the remaining spacing instead of using a fixed CSS
value.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3069
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1581>
This is some leftover from code that was used to keep track of volumes
added/removed while the screen was locked before the move to a
components system in 2a800e4c. All that the remaining code does is
filter devices from an empty list.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1579>
Now that the Dash is horizontal, the popup menu of the Dash icons must
show up, instead of left/right.
Make AppIcon.popupMenu() receive an optional parameter with the side
to show the menu, using St.Side.LEFT as default. Override this method
in DashIcon to always pass St.Side.TOP.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
And move it to the bottom of the overview. Change the height-based calculation
of the icon sizes to be width-based. Put the DashFader in a vertical box, and
make all corners of the Dash equally rounded.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1559>
The SHADE_ANIMATION_TIME variable sets the duration of the animation of
the background shading that is done when showing the overview. As
explained in the code-comment, that value must be smaller than the
animation time of the overview.
Now since we're going to start animating the background color of the
panel when showing the overview and we're going to use the overviews
animation time for that, we want to make sure the shading of the
background image and the animation of the panel are kept "in sync",
otherwise the transitions would look bad.
So slightly increase the value of SHADE_ANIMATION_TIME to 240 (the
overviews animation time is 250) to make sure those happen in the same
timeframe.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
The current way of indicating focus of elements in the panel does not
work very well with a fully-transparent panel, a line at the bottom of
the panel doesn't make too much sense if there is no real panel, but
only the text and icons.
To make the indicators look better in this case, switch to a pill-shaped
background color to indicate the focus of items in the panel.
For this to look good, there has to be a small black border above and
below the background, this also requires increasing the height of the
panel (from 1.86em to 2.2em) for visual purposes.
Also, since we now no longer need to color the lower bottom of the
panel, we can remove the custom drawing code for the border of the
panels corner, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1397>
Currently the hint reflects the `active` state, which effectively
corresponds to the screen blank. That's a bit surprising considering
the name, plus the `active` state is already exposed by the ScreenSaver
D-Bus interface for anyone interested.
It seems reasonable that the `LockedHint` property reflects the lock
state, so change the handling to do exactly that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/351
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1561>
We want to either handle a scroll event ourselves, or delegate it
to the swipe tracker. What we never want is StScrollView's default
handler that doesn't have any knowledge of pages, so disable it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
Even if they're in the end of the list. So far we've managed to not be affected
by this bug because until GNOME 3.38, workspaces didn't have a background, and
there was no way to navigate to these leftover workspaces, but with the proposed
overview changes for GNOME 40 it'll be very much visible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
When handling all scroll directions, it is imperative to ignore emulated
events. Otherwise we may get the wrong scroll direction, e.g. when natural
scrolling is enabled.
Ignore pointer emulated events in WorkspaceDisplay._onScroll().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1560>
All subclasses of BaseAppView now are horizontal, thus we
don't need to deal with the vertical case anymore.
Remove the corresponding parameter from the BaseAppView
constructor, and move the StBoxLayout that both AppDisplay
and FolderView have in common into the base class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1554>
Recent commit [1] added a strong light border around user avatar
icons, in accordance with design mockups.
As a probably unintentional side-effect, the border was also added
around the symbolic fallback icon, which is displayed whenever the
user avatar is not available. This doesn't work well with the current
design, as the strong border makes the subtle fallback icon
background indistinguishable. Additionally, it doesn't match the
design mockups for the symbolic avatar icon [2].
Correct this by adding a style class for when avatar image is used,
and apply the border only for that case.
[1] 498710c2ec
[2] https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/lock-login/username-based-login.png
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1490>
When checking for a suitable icon size, Dash currently checks which
of the hardcoded icon sizes is smaller than the calculated available
size.
On some circumstances, however, when the calculated available size
is exactly equal to the hardcoded icon sizes, Dash selects a smaller
size. This cascades (the next icon size is exactly the smaller size,
etc) and ends up with always Dash selecting smallest size available,
even with plenty of available space.
Check if the calculated available size is smaller or equal to the
hardcoded icon sizes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1533>
Updating scroll position may have significant side effects, e.g.
switching workspace; this should never happen during allocation, as
we're in the middle of painting a frame. So, put it in an idle callback
if we're doing it from an allocation to have the side effects happen the
right time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1527>
Screen magnification is the compositor's business, not that of "random"
unprivileged tools. And for cases where a more specialised behavior is
wanted, an extension likely does a better job than a consumer of the
D-Bus API.
In addition to that, exporting the interface has been broken for an
unknown time, because the object that holds the implementation isn't
referenced and thus ends up being garbage collected, whoops.
And last but not least, this gets rid of the last public D-Bus name
that isn't clearly in the system namespace (org.gnome.Shell,
org.gnome.Mutter, org.gtk).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3452
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1523>
Simplify the opacity dance to simply setting it to the initial value
before animating (0 when animating in, and 255 when animating out),
and to the final value after the spring animation is done (vice-versa).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
To run the spring animation, IconGrid uses the transformed position and size
of the icons. This works okay when IconGridLayout doesn't need to update the
icon sizes, but looks bad when IconGridLayout selects a different icon size.
Wait for the icon sizes to be recalculated, and the icons beallocated, before
running the spring animation. If no icon size update is pending, run the spring
animation directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
In the future, both AppDisplay and FolderView will be horizontal, and thus
using the orientation to determine whether to use animated indicators won't
be enough.
Use a different flag to control that, and make FolderView not use animated
page indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
SwipeTracker connects to signals of the stage, but doesn't disconnect on
destroy, leaving them hanging and potentially running callbacks for
destroyed objects.
This is visible when removing a folder by dragging all icons out, and
running the swipe gestures, which will produce a bunch of warnings.
Explicitly destroy, remove, and disconnect the swipe tracker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
Make it subclass ClutterActor, since we don't need any of StWidget's
features. Pass the source actor of the bind constraint in the
constructor, and remove the extra method to set the source actor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
ControlsLayout is a tiny layout manager whose only purpose
is emit "allocation-changed" after allocation. This signal
was listened to update the workspaces actual geometry.
However, since d66cd0d206, ControlsManager doesn't listen
to this signal anymore, rendering the class useless.
Remove ControlsLayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1518>
How and if notifications are shown is controlled by NotificationPolicy
objects. But ever since 098bd45, only notification daemon sources or
notifications associated with an app are hooked up to GSettings.
The hardcoded default policy for built-in notifications (including
those provided by extensions) arguably made sense back then, but
now that the main setting has been rebranded as "Do Not Disturb"
and is exposed prominently in the calendar drop-down, following
GSettings is a better default.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3291
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1511>
When selecting the best icon size for the available area, we
iterate from the biggest icon size to the smallest one, and
stop when finding a size that fits the available area.
However, the 'bestSize' variable is only updated when the
available area is positive. This is problematic in super bad
cases like when none of the icon sizes actually fit the availabe
area, which was hit with a previous iteration of this branch.
Make sure to update the best size while iterating, so that the
smallest size is selected even in such bad cases.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
Use the Clutter.ActorAlign.FILL alignment by default, which
expands the grid until max-row|column-spacing is hit. This
was the behavior we originally wanted for the icon grid, and
it's finally being realized.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
This is a new property to control the padding around each page,
as opposed to the padding around the entire container.
Following the original design of IconGridLayout [1], changing
the page-padding property doesn't trigger relayouts; the container
is responsible for queueing a relayout appropriately.
[1] 3555550d5e
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1510>
The grid icons in the search results page doesn't expand to
acommodate the multiline label, resulting in the multiline
label to overflow behind the list search results. However,
after 548d3b62d, it was possible to trigger this behavior
with keyboard focus.
Don't update multiline labels for search results.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1509>
Adding children to the WorkspaceLayout without calling addPreview() is
not supported, so let's log an error in case that happened.
We also have to allocate that child an empty ClutterActorBox, otherwise
Clutter will complain loudly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1481>
Clutter expects actors overriding the allocate vfunc to allocate all
mapped children of the actor, otherwise bad things happen.
So make sure we actually allocate all our visible children in our custom
allocation functions, and since we don't want to give them a real
allocation, just pass them an empty ClutterActorBox.
It would be nice if we had a way to hide children during the allocation
process where no relayout is queued like gtk allows with
gtk_widget_set_child_visible(), then we could avoid those weird empty
ClutterActorBoxes.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3098
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1481>
When logging out or terminating gnome-shell, mutter will unmanage all
open windows, triggering the window-close animation in gnome-shell and
very quickly after that emitting "kill-window-effects". That means we'll
call _destroyWindowDone() to cleanup our animation data, but at this
point the MetaWindow of the window is already gone, so we get an error
that get_meta_window() returns NULL.
Fix that by checking whether get_meta_window() returned NULL and if it
did, don't access the window.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2018
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1483>
If the adapt to size occurs after the grid page has been changed the
page is set to zero. This patch just keep the current page with the same
value that it has before.
Fix https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3388
`shouldShowApp()` is called in `_addFavorite`, so adding a favorite when
this isn't true won't work. Also, it seems when this is false, favorites
that do exist won't be shown anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3342
When initializing the shell, we create the magnifier, and (normally)
let it disabled. This still toggles cursor visibility on, which is
not right since there's other considerations to take during
initialization.
Only do this after actual changes to the magnifier state, so
initialization is left unperturbed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1486
When support for notification sounds was added, it made some sense
to keep the 'enable-sound' setting independent from 'show-banners'.
However that changed when 'show-banners' was rebranded in the UI as
"Do Not Disturb", as sounds are at least as disturbing as the banners.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2873
We sometimes add dialogs multiple times to the WindowPreview, for
example for modal dialogs we receive both the "window-added" and the
"window-entered-monitor" signal, which means we call
WindowPreview.addDialog() twice.
We handle that fine already in the WindowPreviewLayout and return NULL
in case the window already was added, so simply handle that NULL return
value and bail out of WindowPreview.addDialog() in this case.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1482
Most media players have a media player that shows the title of a song
and artists in the song. In those media players the title is
highlighted (bold text) and the list of artists is under the title.
Shell does the exact opposite in the player in the notification area.
Example media players: Spotify, Rhythmbox, GNOME Music
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1480
IconGridLayout uses the biggest minimum size to allocate its
children. Next commit will make app icons with long names show
not ellipsize on hover, and it is important that the icon itself
is able to follow that.
Use preferred size if it's bigger than the minimum size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1477
When the icon area gets allocated additional space, we want the
icons centered rather than left-aligned. This may happen in locales
with long-ish translations for the title or buttons when only a
subset of possible icons is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3307
Commit de610a13f1ad1e7e34d4b9a81df58d4da3693059 in mutter made it
impossible to access the actors last allocation after unmapping it,
this broke the scale-up/down animation when starting a drag.
Fix that animation again by saving the actors transformed size before
unparenting (and therefore unmapping) the actor instead of afterwards.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1475
The screen shield code listens for motion events on the stage
so that it can hide the pointer until the user moves the mouse.
Unfortunately, if the user never moves the mouse, the signal
handler connection gets leaked.
This commit makes sure the connection gets disconnected when the
shield goes away.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1459
The screen shield watches for motion events to know to display
the pointer when the user wiggles their mouse.
It checks for motion events by looking at the event type and
seeing if it is of type `Clutter.EventType.MOTION`. To do this
comparison it uses the equality operator (==). Using the equality
operator isn't considered best practice, because it can returns true
when comparing disparate types, if those types happen to be equivalent
after coersion.
From a code resiliance point of view, it's better to use the
identity operator (===), which requires both sides of the comparison
to be of the same type.
As a policy, any legacy code that gets changed or moved should be
switched away from the equality operator to the identity operator, if
appropriate.
This commit makes that change as prep work for a fix to that part of
the code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1459
When using `Actor.ease_property` if the property starts with '@' and the
duration of the transition is zero (which may happen if the actor is not
mapped even if a non-zero duration was passed to `ease_property`), the
impl will try getting the actual target object where the property should
be set.
This works fine for most cases but it currently throws an error when
passing '@content.*' properties. Fix this by handling '@content' as
a property of `actor.content` (used by MetaBackgroundActor when
showing the overview).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1461
The panel corners try to match their style to the buttons closest
to them. In order to make sure the corner styles stay in sync with
their neighboring buttons, they connect to the style-changed signals
of the buttons.
In order to make sure the style-changed signal handler isn't leaked,
it gets disconnected when the button is destroyed.
Unfortunately, the destroy signal handler connection itself gets leaked!
This commit ensures the destroy signal handler gets disconnected any
time the neighboring button is re-determined.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1460
Clutter nowadays omits reallocations when only the stage position
changed, that is when the allocation relative to the parent changed.
As a result (apart from better performance of course), workspaces
in the overview may now end up with an outdated "actual geometry"
in case the overview moved to a new primary monitor (of equal size
as the previous one).
Work around that by emitting a signal from the overview on allocation
changes, and use that to update the cached geometry.
We can revert that change once workspaces become part of the regular
overview hierarchy.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3211
When dragging icons out of a folder dialog, there is a very peculiar
combination of steps that may break GNOME Shell:
1. Open an app folder dialog
2. Start dragging an icon to outside the grid
3. Wait until the popdown animation starts
4. Before it finishes, drop the icon
5. See the warnings / crash
That's caused by the source icon being destroyed after the delayed
move timer starts, and before it finishes.
Protect against the source icon being destroyed before the delayed
move timeout triggers by connecting to the 'destroy' signal and
removing the timeout on the callback. Use a single field, called
'_delayedMoveData', to store all data related to delayed moves.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
When dragging an icon outside of a folder dialog, there's a small delay
before the dialog pops down. If the icon is dropped during this delay,
the drag is cancelled, and the icon continues to be in the folder.
However, this behavior turned out to be problematic, and it was a common
point of failure that throwing icons outside folders wouldn't work.
Remove the icon from the folder when dragging it to outside the dialog.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3092https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
At the end of BaseAppView._clearAnimateLater(), the '_grid' actor's opacity is
set to 255. As it turns out, _clearAnimateLater() is called, among others, by
vfunc_unmap(). However, unmapping is part of the destruction process, and at
the time it is called, '_grid' is already destroying, which makes GJS complain
about accessing an invalid object.
Don't change opacity on BaseAppView._clearAnimateLater(), and instead move it
to the couple of places outside vfunc_unmap() that call it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
After dragging an icon to inside a folder, we do not save the grid layout,
leaving the icon's position stored when it actually isn't there anymore.
Fix that by saving pages whenever folder apps change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
To delete a folder, FolderView needs to reset all keys under that particular
folder's GSettings path. That generates 5 'changed' signals, all of which
end up calling AppDisplay._redisplay(), which is costly.
Don't emit 'apps-changed' when deleting a folder.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
If you try and drop an icon that's in the same page, but before the
drop target, it'll be one position ahead of where it should be -
because we just removed one icon before the target position.
Adjust the final position of the to-be-created folder.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
This new public API moves items without removing and readding
them, which allows us to avoid some tricky behavior. Noticeably,
following the original design described at 3555550d5, the new
IconGridLayout.moveItem() method does not call `layout_changed`.
This is done by IconGrid itself, queueing a relayout.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
When adding an item to the app grid, the item is added to
a sorted array. This is calculated by adding all visible
items in pages before the one being modified. Future commits
will need this to move items without reparenting them, so
factor this code into a separate function.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1447
This was missed in commit 96f63b08c2 when splitting the combined
layout+scrolling method into allocation and translation.
Add it back to prevent windows from other windows leaking into view
during the transition.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3208
We couldn't clip workspaces views during the overview transition
when we used the "porthole" approach, but as view's allocation
now always matches the expected visible area, we can just apply
the clip unconditionally.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3208
Commit ff3d32dd18 added a custom DashIcon subclass that disables
all DND methods from ancestors, including canceling the context
menu timeout and emitting the overview's item-drag-begin signal.
All we want is opting out of the parent's scale-and-fade behavior,
so override those methods instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3209
Currently the width of the calendar column is solely determined
by the calendar, while other elements are ellipsized as necessary.
While that is the desired behavior for the events-, world clocks-
and weather sections, we don't want to cut off the date in the
header. However switching to bold text made that more likely in
non-English locales or when using large text, so explicitly take
it into account for the width negotiation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2230
BaseAppView not disconnecting from the 'app-filter-changed'
signal means parental controls may trigger callbacks on
a destroyed grid, which tries to access destroyed icons,
which spams the journal with stack traces.
Disconnect from parental controls when BaseAppView is destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1441
It's best to not mix transient indicators with (probably) permanently
visible items, so move the remote-access indicator (which also handles
screencasts now) to the position of the old screen recorder icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1438
A window preview's floating geometry is scaled down according to the
workspace's allocation, while the layout geometry is computed directly
for the available space.
For previews that maintain their real size in the layout geometry,
that scaling leads to a distracting size bounce when transitioning
between both layouts.
Address that by not allowing the scaled floating size to drop below
that layout size (which is at most equal to the unscaled floating size).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2968
As per GSettings documentation, it is necessary to read a particular
key at least once before being able to connect to the corresponding
'changed::' signal.
Read the 'app-picker-layout' key before connecting to the changed
signal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1428
It is wasteful to emit layout-changed when updating pages, because
the caller (AppDisplay) already has an updated state by the time
this is called.
Only emit 'layout-changed' if the GSettings notification doesn't
come from AppDisplay updating the pages.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1428
widget.get_effect(...) can return null while locking the screen, resulting
in a TypeError. In this situation the screen ends up black with a cursor
but never going to sleep, and moving the mouse brings the old screen
contents up but does not allow unlocking.
unlockDialog.js assumes that widget.get_effect will return non-null,
but other places such as getWindowDimmer in windowManager.js go out of
their way to be more careful.
[smcv: Add commit message, remove hard tabs, add missing semicolon]
Resolves: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3071
Bug-Debian: https://bugs.debian.org/968440
When promisifying async operations in commit 764527c8c, the
finish function for read_line_async() was sneakily changed from
read_line_finish_utf8() to read_line_finish().
That is, the call returns a Uint8Array now that requires an
explicit conversion to string.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1407
Since gjs moved to mozjs60, return values of int8_t arrays can
no longer be treated as strings. We originally made the conversion
conditional to keep working with the (then) stable gjs release.
That was two years ago and we require a more recent gjs nowadays,
so there's no good reason for keeping the old code path.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1407
When the last item of an IconGridLayout page is removed,
the page itself is removed too. However, the indexes of
items of next pages are not updated, which mess up the
layout manager state.
Update the page index of the items at forward pages when
removing a page.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1406
global.run_at_leisure() is used from automated scripts to schedule
a callback when the shell is idle. However since we moved away from
Tweener, animations are no longer taken into account; fix this by
marking transitions as "work" if the convenience ease() functions
are used.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1396
The original scripting framework was based on SpiderMonkey's
pre-standard generators, and was simply translated to the
corresponding standard syntax when updating it to work with
recent JS versions.
We can do even better by using the standard async/await pattern
instead of generators/yield.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1396
If the user's battery power is low, we should not check the checkbox to
install updates by default. Rationale: if the user's battery is not low,
it's very unlikely to run out during a normal system upgrade. Low
battery is defined as any level below 30%, matching our battery status
indicator.
We'll also change the battery warning to only display when battery is
actually low. However, we will still always warn on battery for full
system upgrades, since these are expected to take a long time.
Future improvement: it would be nice to make the checkbox insensitive
when on low power. However, I don't think we currently have a proper
style for insensitive checkboxes. I was unable to make it look good.
Lastly, note that I did not test this on a laptop. I tested this by
mocking the return values of _isDischargingBattery() and
_isBatteryLow().
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2717
A side effect of removing the action buttons in favor of a regular
submenu is that we are a lot less constrained by size. So instead
of lumping "Restart" in with "Power Off", make it a separate menu
item.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2202
We will split off restart from the existing shutdown dialog, and
instead offer it as a separate menu item in the session submenu.
But before doing that, make sure that the existing restart dialog
exposes the same feature set as power off.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2202
This implements the "Alt" behavior for the "Reboot" button as outlined in
the design here: https://wiki.gnome.org/Design/OS/BootOptions
Note I've tried implemeting this with the AltSwitcher class from
js/ui/status/system.js first, but that puts the button in a St.Bin()
which causes the button to think it is the only button on the dialog
and makes it have rounded corners on both of its bottom corners.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/199
Immediately add buttons to the dialog instead of first building an
array of button-info structs.
This is a preparation patch for adding support changing the "Reboot"
button into a "Boot Options" button when Alt is pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/199
Fix what is probably a copy-paste error and return false instead of a
CONTINUE DragMotionResult which is only meant for dragMotion events, not
drop events. This makes sure we don't create a folder when dropping an
app over the drag leeways of another icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1389
For more obscure network configurations, we need to launch the
corresponding Settings panel with additional parameters, so we
cannot simply launch the .desktop file.
However we can do better than spawning a command line: Control center
exposes an application action we can use instead, so the process is
launched with the appropriate activation environment and startup
notification support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1385
This fixes an issue where the indicator can be out of sync until the
RfkillManager (used by it) properties change.
The problem is that multiple instances of the indicator will use
the same RfkillManager instance (getRfkillManager() returns a singleton)
that only guarantees to emit the changed signal in two scenarios:
when the D-Bus proxy connects and when the proxy properties change.
If by the time an indicator is instantiated the RfkillManager's D-Bus
proxy is already connected, that indicator would only sync its state
when the RfkillManager properties change.
Let's fix that by always syncing the state on construction - in the worst
case scenario the RfkillManager's D-Bus proxy won't have connected yet
and the indicator state will be temporarily out of sync but once it gets
connected the indicator will sync again with the correct state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1386
To do this, we now wait for the start/stop job to complete. We also have
two targets in gnome-session to ensure that everything is working as
expected.
In order to start the services, we simply request the
gnome-session-x11-services-ready.target unit, and wait for it to become
available. To stop, we use the gnome-session-x11-services.target unit
which should stop all services in a way that is entirely race free.
This requires both gnome-session and gnome-settings-daemon changes to
work (which are in the corresponding merge requests).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/895
Move the screencasting into a separate D-Bus service process, using
PipeWire instead of Clutter API. The service is implemented in
Javascript using the dbusService.js helper, and implements the same API
as was done by screencast.js and the corresponding C code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
If a remote access is marked as a recording, visualize it the same way
as a built in recording. Also don't stop it if there is an actual screen
sharing going on, so that one can use a plain "recording" while still
disabling what is an actual screen sharing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
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
