For the primary monitor workspace thumbnail, we must keep the monitor
index in sync with what is currently the primary monitor index,
otherwise we might end up trying to move windows to non-existing
monitors.
For example, if the primary monitor index was 1 when the thumbnail box
was created, but later, the primary monitor index changed to 0, with the
other monitor being turned off, moving a window to one of the workspaces
on the workspace thumbnail, gnome-shell would attempt to move it to the
monitor with the index the primary monitor had in the past, with the
problem being that that monitor no longer exists.
Fix this by listening on the 'monitors-changed' signal on the layout
manager, and update the monitor index of the primary workspace
thumbnails box. Make sure to connect to the signal before creating the
thumbnails box, as the thumbnails box itself will listen to the signal
and recreate its actual thumbnails, and it must do this with the up to
date monitor index.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1810>
When OverviewControls goes from HIDDEN to APP_GRID, it constantly checks
if AppDisplay needs to be visible or not by checking the current overview
state is bigger than WINDOW_PICKER. Turns out in this case this check is
problematic, because when the current state trespasses WINDOW_PICKER, the
layout manager will have already positioned AppDisplay halfway to its final
position.
Use either the final or the current state, whichever is biggest, when updating
the AppDisplay visibility. It optionally allows passing the overview state
params to _updateAppDisplayVisibility() so that we avoid a few trampolines to
recaltulate the adjustment state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1805>
Both app grid and window picker are now always visible in the overview,
so their handling of the PgUp/PgDown keys conflicts.
Resolve that by checking for the overview state instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1798>
Window previews looks slightly offset to the left and top right now
because we don't use the same padding on all edges of the Workspace. We
do that because the oversize and overlap of the window previews is
different on all sides (for example the bottom overlap is very large
because there we show the window title).
To make sure window previews are always perfectly centered on the
Workspace, only use the largest one of the oversize values as spacing
and padding, and add the larger one of the overlap values for the
vertical padding in addition.
With this, we now center the window previews on the Workspace while
never overpainting the allocation of that Workspace to show overlays.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3634
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1670>
We only want to show the welcome dialog in the user session, not
on the login screen or during initial setup. We currently achieve
that by explicitly checking for those mode names, but there are
other modes like gnome-classic where the dialog is equally un-
helpful. Support those cases by adding a session mode property
that determines whether the welcome dialog should be enabled,
so that modes can opt in or out of the feature themselves.
(Both the 'gdm' and 'initial-setup' modes are based on the
'restricted' mode, so this change does not affect them)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4026
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1793>
Usage of GET requests for checking updates was made deprecated
at website some time ago [1], but REST endpoint was
CSRF-protected until recently [2].
The body of update request may be big enough and thus does not
suitable for GET requests.
[1] 0b38da1b2b
[2] e3ab0c07dc
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1781>
`key` is an empty string in this case, causing `charCodeAt(0)` to return
`NaN`, which when passed to `Clutter.unicode_to_keysym` now generates an
error in gjs >= 1.67.3:
```
JS ERROR: Error: Argument wc: value is out of range for uint32
```
And the symbolic keys like Backspace, Enter and Caps Lock would have their
presses ignored.
Just skip the call to `charCodeAt` that will fail and allow
`Clutter.unicode_to_keysym` to return its usual error flag.
Fixes: https://bugs.launchpad.net/bugs/1918738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1758>
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:
```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```
And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.
Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.
Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
Right now we use a ClutterClone ghost of the panel simply to add some
spacing to the top monitor edge.
We can remove the panelGhost by adjusting the allocations of all the
parts of the overview ourselves inside ControlsManagers vfunc_allocate,
this should also work with extensions that move the panel somewhere
else.
This makes the initial relayout of the overview significantly faster,
because we now no longer have to relayout the whole panel in the
process.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
The OverviewControls actor gets allocated a fixed size by its parent,
the OverviewActor, anyway, so it's pretty useless to go through the size
request machinery and add up all the sizes of items in the iconGrid,
coming up with a preferred size that's wrong anyway.
Instead simply return a min and preferred size of 0 in
get_preferred_height/width of ControlsManagerLayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
Hiding actors allows excluding them from layout, so by hidding the
appDisplay in all the cases where the overviewAdjustment is not actually
showing it, we can save a lot of time on the first frame of painting
the overview because we no longer have to layout the whole appGrid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
The logic that decides whether we should shift the window up when the
cursor rectangle overlaps with the keyboard rectangle doesn't work
properly right now, we want it to work like this:
- If the currently focused window is shifted up, keep it shifted up
until the cursor rect no longer overlaps the keyboard rect. To do that
comparison correctly, we need to adjust for the height the cursor rect
is shifted up by (keyboardHeight) and temporarily shift it down again.
- If the currently focused is not shifted up, we want to shift it up as
soon as the focus rect overlaps the keyboard rect. If that's not the
case, want still want to call _setFocusWindow(null) in order to shift
the previously focused window back down.
This fixes two issues: 1) We're currently shifting windows back down at
the wrong position of the cursor (that is y < keyboardHeight). 2) We're
not shifting down previously focused windows when focusing a different
window with the new focus in a specific region (y >= keyboardHeight &&
y + h < monitor.y + monitor.height - keyboardHeight).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
So far the FocusTracker of the OSK can only recognize grab ops on a
window, that is when the user grabs the window using a mouse or the
touchscreen and actively drags it somewhere.
Window can also be moved using keyboard shortcuts, fullscreen buttons or
other ways which don't rely on grabs. Start also supporting those window
movements by listening to the "position-changed" signal on the currently
focused window and emitting the new "window-moved" signal in that case.
Because the OSK sometimes moves windows by itself, we temporarily
disconnect from that new signal while we move the focused window in
_windowSlideAnimationComplete().
This also takes care of resetting this._focusWindowStartY on movements
of the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
Commit 8526776b4a changed the OSK to use
the translation-y property of the MetaWindowActor when animating a focus
window, which broke two things:
1) It's not compatible with the obscured region culling we do for
windows in mutter. That's because MetaCullable strictly operates in
integer coordinates and thus has to ignore any transformations
(translation-y is a transformation). Because of this, during the
animation and gesture, window damage is now tracked incorrectly,
introducing painting issues. The best fix for this would probably be
factoring in transformations when tracking damage in MetaCullable, but
that's not feasible right now.
2) It broke the shifting up of maximized and tiled windows, likely that
is because they are positioned using constraints internally, and mutter
enforces those constraints every time meta_window_move_frame() is
called, not allowing the window to move somewhere else.
To fix both issues, go back to the old way of shifting the window for
now, using the fixed y position of the ClutterActor. To make sure the
drag-up gesture still works, store the initial y1 position of the window
and then use that as a reference point for all our animations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
I suggested it myself when reviewing
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668, so
here I am reverting that again...
The difference between calling _setFocusWindow(null) and simply
unsetting the focusWindow is that the former animates the window back to
its position before we shifted it up, while the latter simply "lets go
of the window".
In this case we actually want the latter because after the user grabbed
the window, we obviously should not animate it away right underneath the
users pointer/finger.
To ensure the same mistake doesn't happen again, add a small comment
explaining why this code is as it is.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1760>
If the actor is unmapped in the handler, the touch gesture will cancel.
Since we haven't reset the state yet, it will still work and will actually
cancel the gesture, so reset before that instead.
Fixes overview cancelling when trying to open it with a swipe.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
When this class was written, all swipes in the shell were vertical, so it
made sense to make the default orientation vertical. This isn't the case
anymore, thus pass make it mandatory to specify orientation when creating
a tracker.
Change the property default values to horizontal as well to match Clutter
instead of the old shell design.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1731>
The focus rectangle of the OSK currently gets stored with an offset that
removes the global coordinates and makes it window-local coordinates.
This offsetting has been applied since the introduction of the
FocusTracker with commit fc5ab44704 and it
seems there's no real reason for it.
By removing this, we also emit position-changed when the window has
moved but the window-local coordinates stayed the same. We really want
to emit position-changed in that case because it might affect whether
the window needs to be shifted up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Apparently some clients, including gtk don't "clip" the focus rectangle
to their window bounds when scrolling the focus outside the window. This
makes us shift up windows when the focus actually is no longer visible.
This issue needs fixing in GTK, it should probably stop reporting
focus changes when the focus moves outside of the visible view. We can
still do a little bit better on our side though and "clip" the rectangle
to the windows frame rect: If it moves out of the window, we simply stop
updating our focus rect.
The intersection check introduces a small problem though: Some clients
(for example gedit) will give us a cursor rect that has a 0 width or
height. This won't play well with graphene_rect_intersect()
(GrapheneRects never intersect if they are 0-sized), so we set the size
to 1 in case we get a 0-sized rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
The FocusTracker keeps track of the currently focused window using its
internal this._currentWindow property. It will only pick up the focused
window though when receiving a "notify::focus-window" signal, so the
focused window that's set when the FocusTracker is created won't be
picked up.
Fix that by setting the _currentWindow during creation of the
FocusTracker.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Now that we got rid of the external calls to setCursorLocation(), we can
make that private. animateShow() and animateHide() weren't called from
outside anyway, so let's make those private, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
What this signal does is fire when a window was grabbed. A receiver
might want to do something special when a window was grabbed, whereas
"reset" can mean anything. Rename the "reset" signal to
"window-grabbed".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1728>
Instead of interpolating our workspace and layout boxes for each child
using clutter_actor_box_interpolate(), use our Util.lerp() function and
stay in JS land instead.
This is quite a large performance improvement since it avoids
heap-allocating a new ClutterActorBox for every child. With this, we're
finally at a duration of 1.0 ms to allocate the Workspace with 20
windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.
This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
It turned out that getting properties and saving them to a variable
outside of loops instead of accessing them everytime inside the loop can
have significant impact on performance, so do that in Workspaces
vfunc_allocate().
Here the impact is not that large, about 0.05 ms with 20 open windows,
that still seems worth it though.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
These checks aren't needed since Clutter should enforce this for us
already and skip the implicit transition when possible. This gets our
time spent in vfunc_allocate() down to 2.0 ms with 20 windows
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
Setting four properties is more expensive than calling two C functions,
so move to set_origin()/set_size() calls for our ClutterActorBox
handling.
This gets us down to an average time of 2.1 ms spent in vfunc_allocate()
with 20 windows
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
We can save a little bit of time in this loop by iterating directly
over the windowSlots array instead of iterating through children and
then performing a search for the windowSlot. This saves more time and we
only spend 2.2 ms instead of 2.3 ms in vfunc_allocate() now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.
We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.
In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
Right now we always recreate the icon of the appMenu when calling
_sync(). This will relayout the panel everytime we open the overview,
because we call _sync() in that case.
We can easily avoid that by only recreating the icon actor in case the
app that's opened actually changes. This gets us close to doing no more
relayouts of the panel when opening the overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
We already set the AppMenuButton to be non-reactive and transparent when
we hide it. Hiding it completely using clutter_actor_hide() will
additionally make it no longer affect layout and thus queue a relayout.
Since we hide the appMenu in the overview and we want to avoid
relayouting the panel when entering and leaving the overview, don't
completely hide the AppMenuButton to avoid queueing this relayout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
This updates the use of bind_cairo_surface_property for the changes
from d7cb2eeebc. Now this function returns a StImageContent and not
an Actor like the following code expects, so wrap it in a StIcon.
Also the function lost its size argument.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the window wasn't in _windowSlots, the index is -1, so the last
element of the array is removed, leading to
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547
I logged the stack trace from removeWindow() and it seems that when you
move the window from the second monitor to another workspace like shown
in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3547,
removeWindow() is called twice for it, presumably once for the second
monitor workspace, and then once for the first monitor workspace for
some reason. It is during that call that _windowSlots doesn't contain
the window, so instead the last element (index -1) is removed, leading
to the animation bug.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1727>
We block state updates while the indicator for the active workspace
is animating. To track that, we check whether the scroll-adjustment's
value matches the active workspace index. That works as long as the
adjustment's value changes after the active workspace, but not when
switching workspaces via SwipeTracker which only changes the active
workspace after transitioning to the new scroll value.
To fix that, update the indicator on workspace changes as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1716>
Animating items of the iconGrid involves calling a few more C functions,
which is quite slow. Especially calling ClutterActor.set_easing_delay()
is slow because we override that function in JS to adjust for the
animation slow-down factor. So add a small class variable to make sure
we only animate the icons of the grid when we actually need it.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down to about 0.7 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
It's quite slow to access class variables in JS, especially when they're
backed by GObject properties. To avoid accessing them in every iteration
when we're looping through the children of iconGrid, store those values
to another variable and reuse that inside the loop.
This shaves off another 0.2 ms from iconGrids vfunc_allocate(), getting
the average time spent in that function down from 1.3 ms to 1.1 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
Using a preexisting array to iterate over is much faster than iterating
over the actors children using a "for ... of" loop, that's because the
latter calls into C functions to get the next actor all the time.
Also, stop using array deconstruction here, it turned out that this is
extremely expensive. When profiling this part of the code, it turned out
that only 9% of the time spent in _getChildrenMaxSize() is spent calling
the get_preferred_height/width() methods. When not using array
deconstruction, this time increased to 22%, still not great, but a lot
better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
We need to access the visible children of a page in inside
vfunc_allocate(), and since getting those children is quite slow (it
involves iterating over all the children of the actor) let's avoid that
and cache the array instead.
This reduces average time spent in vfunc_allocate() of the iconGrid from
1.6 ms down to 1.4 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
We call this._getChildrenMaxSize() from the allocate() vfunc of
IconGridLayout. Since the function is quite expensive, it slows the
layout process down a lot, so instead of re-calculating it on every
relayout, cache the max size of children.
This makes the average time spent in vfunc_allocate() of the iconGrid go
down from 2.3 ms to 1.6 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1713>
Instead of always aligning window previews vertically at the bottom of
their row, only do that if we have multiple rows. If there's only a
single row of windows, align every window vertically centered.
This is a very small step towards the new layout for window previews in
the overview, but since the release of 40 is getting nearer and nearer,
changing more is not feasible anymore.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3634
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1737>
To ensure the workspace thumbnails are vertically closer to the window
picker than to the search, scale down the wallpapers by a fixed number
of pixels. Using 24 px for this means we'll take of 12 px at the top and
12 px at the bottom of the wallpaper, that's a better strategy than
always scaling it by a fixed factor since it doesn't change with the
monitor size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1702>
The back → transparent transition gives it a very bad look when
booting and running the startup animation.
Use the same transition duration hack to ensure that the panel
starts completely transparent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
There's this little hack that we do to match the panel transition from
transparent to black with leaving the overview via swipe down. The only
problem is that, while the duration of the panel transition itself is
matches, the corners don't, and they get out of sync.
This isn't very noticeable with the swipe gesture, but it'll be much
more prominent when booting straight into the overview.
Bind the 'style' property of the panel to the corners', so that the
transition duration hack applies to all of them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
The new startup animation consists of rising the Dash from the bottom,
falling the search entry from the ceiling, and going from HIDDEN to
WINDOW_PICKER with an opacity applied.
One little trick from IconGridLayout was added to ControlsManagerLayout,
which is a promises-based wait for allocation. This is required to make
sure that the transformed position of the search entry is valid, which
is only the case right after an allocation.
This animation also ensures that the overview is shown right on startup.
For session modes that do not have an overview, continue using the same
fade + scale animation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
We want to avoid updating the input region on startup, since it incurs
in roundtrips to the X server, but not workspaces struts, since they
affect the visible clip of wallpapers in the workspace. Since next
commits will make the overview be the after-boot screen, we really
don't want the wallpaper to be clipped wrongly.
Allow updating regions while starting up, but only workspace struts.
Make sure input is not updated by accounting for 'this._startingUp'
on 'wantsInputRegion'.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
This is an X11-specific routine, and building the list of input region rects
on Wayland is a waste, since it incurs in many trampolines only to throw them
in the trash.
Don't build input region rects on Wayland. By modifying the 'wantsInputRegion'
variable, it also skips actors that only update input, which is another small
optimization for Wayland.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
LayoutManager doesn't update struts when there's any modal running. Turns
out, the Overview itself is a modal. That, and the fact that the Overview
will be the startup state, prevents the workarea to be updated.
Allow updating struts when there's no other modal than the Overview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1678>
Let the goToPage call afterwards to take precedence, instead
of resetting the adjustment (thus the view) on the side.
This resulted in strange state when the last page contains
a single icon, and it is dragged. The last page being emptied
triggers a pages-changed signal, which half resets the view
to the first page while DnD is ongoing.
Letting goToPage do its business means we neatly clamp to the
closest page to currentPage, the last page in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When clicking on the page hints, the hint rectangles being visible
in place and not moving together with the page is a bit too
distracting.
Since the page hints are not part of the iconGrid hierarchy and
we have just 2 general ones for prev/next page (i.e. no page
associated), do this sliding via some smoke and mirrors: We don't
slide the page hints, but a parent container for both of them, and
we also control opacity so that the container is fully transparent
mid-page. At the point it is transparent, the container can be
snapped to the other side of the page, and faded back in as it
slides together with it, so it always looks like it goes away and
comes from the right sides.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Depending on the available horizontal space, we may want to manipulate
the icon grid and scroll view spacing to result in an optimal layout
that has space left to preview prev/next pages.
The main change here is that, when adapting to the available size, the
space given to a page does not necessarily match the available space,
as we need to be able to show more than one page at a time.
With this decoupling of available and page sizes in place, we now know
how much space there is available in order to extend the padding between
pages, or the fade effect applied to the previewed pages.
Underneath, we rely a bit less on hardcoded CSS paddings, and a bit more
on the StScrollView::content-padding property.
All put together, gives us proper space management from ultra-wide
displays, to display ratios that are close to the optimal grid ratio.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When DnDing an icon, we show both previous/next page, and optionally
a "placeholder" actor to allow creating new pages. These sides on the
scrollview are drop targets themselves, allowing to drop an app onto
the next/prev page without further navigation.
Still, preserve the checks to maybe switch to prev/next page without
finishing the DnD operation, for finer grained operations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Add the necessary animations to slide in the icons in the previous/next
pages, also needing to 1) drop the viewport clipping, and 2) extend scrollview
fade effects to let see the pages in the navigated direction(s).
The animation is driven via 2 adjustments, one for each side, so they
can animate independently.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
We want to show left/right side pages during navigation, also in
FolderViews. Let this scrollview use the same style than the "all
apps" one, and generalize the name a bit.
This will compress the scrollview horizontally, so there's actual
overflow space to show these pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
The workspace minimap is much less prominent than the old workspace
switcher, and serves primarily as an indicator.
That means that duplicating it on secondary monitors (if workspaces
on non-primaries are enabled) is harder to mistake for per-monitor
workspaces, so make some people happy by including the minimap on
every monitor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Now that the backgrounds was moved into workspaces, the fullscreen
views on secondary monitors are visually inconsistent with the
primary view, as there's no dash or search entry that reduces the
available height and allows adjacent workspaces to peek in.
Address this by adding padding above and below the view, so that
it is limited to 70% of the available height.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
Right now the handling of external monitors is relatively simple, and
consists of putting either an extra workspace or a full view on the
monitor, depending on the workspaces-only-on-primary setting.
We are about to tweak the behavior on secondary monitors, prepare for
that by splitting out an intermediate actor that manages the views on
non-primaries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment views on non-primary monitors take up the entire work area,
so simply allocating the available size works. However we'll soon shrink
the views a bit to match the visuals on the primary monitor. As workspaces
keep the ratio, reducing their height will also reduce the width; override
the default allocate() to keep the extra workspace horizontally centered.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
At the moment, we only get the initial :should-show value when populating
the thumbnails. That only happens when entering the overview, so any
listeners to notify::should-show will perceive it as a change rather
than an initialization, which can result in unwanted transitions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
We currently initialize the porthole to the screen size instead of
the monitor's work area we actually want. At the moment this doesn't
matter, as the minimap is created during initialization with the rest
of the overview, so we can expect a work area change that updates the
porthole to the correct values.
That won't be true for minimaps we put on secondary monitors, so make
sure we initialize the porthole to the actual values.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
The minimap is currently created once when populating the overview,
and kept around until the end of the session. That will change when
we start to also show it on secondary monitors, so do proper clean
up when destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1735>
This is used to detect whether a click was short enough to select a
window and activate it or long enough to start a drag. Usually when
clicking on a window and selecting it, this leaves the overview, but
when clicking on a window on a neighboring workspace, the overview is
kept open, but selected is not unset in this case. So all attempts at
dragging the window after using it to switch workspaces will fail.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3783
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1717>
The property describes the target visibility (that is, the visibility
that will be set after the ongoing transition), and is therefore updated
at the start of the transition rather than from hideDone().
The overview gesture currently misses resetting it at the end, so it
is only updated to the correct state the next time the overview is
entered.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1726>
Since commit 9980c80619, the porthole position is ignored. As a result,
previews are only shown if the primary monitor is located at (0, 0).
To fix this, we either need to propagate the porthole to every thumbnail,
use a custom layout manager that applies an offset to all children, or
add an intermediate actor that offsets the contents.
The last option is the simplest and doesn't require calls into JS on
every allocation, so pick that one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3781
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1721>
The preview was getting scaled up by a factor based on what is needed to
increase the width by activeExtraSize pixels. With windows that are
wider than than they are tall, this means that the size of the window
will not increase any more than activeExtraSize in any direction, but
for windows that are taller than they are wide, the vertical scaling
can exceed this. This would break some of the assumptions in the
reported size for the preview chrome and could for very narrow windows
result in a rather large scale.
To fix this, calculate the scaling factor based on whatever is larger,
the height or the width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1707>
Since commit 0f1b566918, we use gjs' automatic getters/setters for
the shader properties. Those handle the properties on the JS and
GObject side, but they don't update the corresponding uniform,
whoops.
Revert the lightbox bits of commit 0f1b566918 to get the effect back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1712>
In the allocate() vfunc of WorkspaceLayout we use a small trick to make
the nonlinear animation paths when opening the overview less jarring:
Because a window might get smaller than its target size during the
animation, we make sure the size never drops below the final size
calculated by the layout strategy.
In the app grid the Workspace is very small though, and the size of a
window slot calculated by the layout strategy might actually be larger
than the workspaceBox. This means we might use the window slot size
instead of the workspaceBox size and end up with a window that's at the
correct position, but its size is too large.
Fix this by only applying this trick when we're animating towards or
from the state where we actually expect the workspaceBox to be larger
than the window slot, that is during the the transition from the session
to the window picker (or the other way round).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
It should be allowed to set this._spacing to 0 and thus pass 0 as
rowSpacing or colSpacing to this._adjustSpacingAndPadding(). The current
if-condition there won't add the oversize to the spacing in case 0 is
passed though.
So change that if-condition and explicitely check for null instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1698>
Window previews can spill out of the container when their position in the
session overflows the monitor boundaries. In the past, Workspace didn't have
a visible background, and was (almost) always fullscreen, which would mask
this particular problem. However, nowadays, it is very much noticeable when
this situation happens.
Clip the window previews container to its allocation when the overview state
is bigger than WINDOW_PICKER. That is, between HIDDEN and WINDOW_PICKER states,
inclusive, no clipping is applied.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
Instead of adding it to the window previews container, add it to Workspace
itself. This requires expanding WorkspaceBackground, so add the relevant
x and y expand flags.
Since the background is beneath the window previews, create and add it before
the window preview container.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
Currently, Workspace is a single actor that contains both the background,
and all window previews, and is managed by WorkspaceLayout. In the future,
this concentrating aspect of it will bite us; we want the window previews
to be clipped to the allocation, but not the background, since it will
have shadows.
Make Workspace subclass St.Widget with a ClutterBinLayout as layout manager,
and move window previews to a child actor. To reduce the impact of this
extra actor, it's a ClutterActor instead of a StWidget, and the spacing is
still set on Workspace itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The WorkspaceBackground class has specific code to clip the background
to the workarea. However, it doesn't monitor for workarea changes, which
means it cannot react after being created.
Connect to 'workareas-changed', and update the workarea, the radius bounds,
and relayout when workareas change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The primary workspace is displayed in the overview, and clipping it
ends up clipping the shadows too. Since Overview's ControlsManager
itself clips to allocation, no windows in the primary monitor spill
to other monitors. However, not clipping non-primary monitors might
end up in situations where their windows spill into the primary one.
Make sure to only clip workspace views of non-primary monitors.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1691>
The dialog is shown at session start, which right now means in the
regular session, however the plan is to start the session in the
overview. When that happens, the "Take the Tour" button should get
the user to the Tour without additonal actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1699>
Right now the rowSpacing and columSpacing of the layout strategy is
calculated by looking at the overlapping sizes of the close button and
the app icon of the WindowPreview, plus a constant spacing read from CSS
by the WorkspaceLayout that's added to that. We're not factoring in the
extra size of the scaled-up WindowPreviews here and instead depend on
the constant spacing being large enough. If we don't want to depend on
the spacing here, we should add the scaled-up extra size to the sizes
returned by chromeWidths() and chromeHeights().
Since the last commits all previews scale up by the same amount of
pixels, so we can now just add that size to the values returned by
chromeWidths() and chromeHeights().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Scaling differently sized WindowPreviews by a constant factor will
result in smaller windows getting enlarged by a smaller amount of pixels
than larger windows (1000*1.02=1020 but 100*1.02=102, one will grow by
20 pixels and the other one by 2), this can look a bit weird because
smaller windows don't scale up as much as larger windows.
So introduce a constant extra size to use when scaling windows up, we
set only the half size there because we want to ensure that the size
added on both sides is not fractional and we remain aligned to the pixel
grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
Right now the spacing between icon and title works using a little trick
that doesn't really seem intended: The title is offset by
(icon-height * ICON_OVERLAP), when the icon is actually overlapping the
preview by ICON_OVERLAP, and *overflowing* the preview by
(1 - ICON_OVERLAP).
So correct that and offset the title by
(icon-height * (1 - ICON_OVERLAP)), and since now there's no spacing
anymore, add a proper ICON_TITLE_SPACING to that offset.
Also add the new ICON_TITLE_SPACING to the overlapHeight, where the
spacing was ignored so far.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1692>
The scale property tracks the relative size at which we display thumbnails
given the space we have available.
That assumes that the allocation represents that available space, but it will
actually be smaller while the minimap itself is collapsing.
Luckily we have an easy option to avoid a distorted scale: Just don't update
it while collapsing. We expect scale changes when adding or removing thumbnails,
but as we freeze those during transitions, we can do the same with the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
Right now the minimap only hides itself in case of a single static
workspace. That's not only an edge case, but also not expected to
change while the overview is visible, so changing the visibility
without a transition is fine.
However that is about to change, and we'll hide the minimap as well
when there are fewer than three workspaces. As that condition is
very much expected to change from within the overview, the transition
should be animated.
Implement that via a new :collapse-fraction property on ThumbnailsBox,
and use that to transition both the height of the box itself and the
scale of the individual thumbnails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
We currently have two components that show or hide the minimap:
- the thumbnails hide themselves in case of a single static workspace
- overview controls show the minimap when no search is active
That obviously doesn't work correctly.
To fix this, change thumbnails to set a new :should-show property instead
of the visibility, and let the overview controls take it into account
when changing the visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3739
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1696>
As planned and shown in the mockups for GNOME 40, round the corners of
the background wallpaper of workspaces.
To do that we use the new rounded-clipping support of
MetaBackgroundContent and we animate the radius by attaching it to the
stateAdjustment just like everything else.
Because we show only a part of the wallpaper and "cut away" the area of
the panel in WorkspaceBackgrounds vfunc_allocate(), we also need to set
the rounded clips bounding rect to the rectangle we're actually showing,
otherwise the texture would be rounded in the region that's cut away.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1651>
This is the same as the vertical swipe gesture, but for keyboard
junkies: Analoguous to the <super><alt>left/right shortcuts for
switching between workspaces, add <super><alt>up/down to shift
between session, window picker and app grid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1695>
The animation handling is kinda split between layout (for the
keyboard slide), and keyboard (for the focus window slide). It
would be nice to have more fine grained control on those, so
move the animation handling altogether to keyboard.js as a start.
This is roughly similar, except that transformations apply to
the Keyboard actor, instead of the keyboardBox (its parent). We
now queue a relayout after the animation in order to update the
chrome tracking.
The only layering break now is that we emit
layoutManager::keyboard-visible-changed in keyboard.js, its
purpose will be dropped in future commits, so leave it there for
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1668>
Gestures leaving the overview from a short distance result in an
ugly effect with the panel opacity transitionhaving a fixed duration.
Make this transition have the same duration (although in a hackish
way) so we avoid the ugly effect.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
The gesture internally manipulates the main adjustment so one swipe
up brings up the overview, and a second swipe up brings the app
grid. The gesture also works in the other direction to get out of
the overview.
Internally, this is delegated on the OverviewControls, so the
adjustment is not leaked out of there. This however meant open
coding the gesture interaction so it can be directed from
overview.js code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
This will be set whenever an event controller is manipulating the adjustment.
It should enter the same transitional state it does for animations. This
will be used by the overview gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Separate this logic from _switchWorkspaceBegin() and ensure it is set
before this call. The SwipeTracker code uses the orientation to determine
whether the gesture should begin at all, so changing the orientation on
gesture begin was a bit too late.
But also, that meant the SwipeTracker was left at the default orientation,
which was vertical (unlike workspaces, and like the overview gesture).
This made both swipe trackers try to handle the same swipe, with the
WorkspacesView being doubly unfortunate (for triggering in the first place,
and for happening after the other gesture did queue relayouts on it).
Taking this logic outside of _switchWorkspaceBegin() and having the right
orientation beforehand results in both gestures looking for their direction,
and not meddle with each other.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touch swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the touch events and look if it matches
the expected orientation before accepting the gesture.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Make the touchpad gesture keep track of its state, and enter in a
rejected state if the swipe is happening in the wrong direction.
Effectively, this means touchpad gestures are locked on a single
direction, and horizontal+vertical swipeTrackers won't be handling
events at the same time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
We now have multiple touch swipe gestures with matching fingers and
different directions set on the overview hierarchy. Accepting all
touchpad swipes without checking the direction makes one of these gestures
take control of input, without other gestures having a say on this.
So, look for the direction of the swipe events and look if it matches
the expected orientation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1643>
Some actors don't have the scale applied to them directly but are
children of a scaled parent. In those case just retaining the scale will
not be enough and the scale of the actor itself needs to be adjusted
when reparenting. This could for example be seen when dragging windows
from the workspace thumbnails.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1687>
Even if activePage has been removed as part of commit 27627bd40, we've
still a reference of it in key press handler.
Given that there's no anymore an active page to redirect input to,
remove these references, so that can be handled in the proper view to
implement key-navigation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1688>
When opening a large number of windows, the computed space and scale for
a layout can become negative due to the per-row/per-column spacing. This
is smaller than the initial values of lastSpace and lastSpace, leading
to a null return which then causes all sorts of other issues resulting
in the workspace becoming invisible.
This change ensures that the function always returns a layout, even if
it may look a bit broken and does not conform to the scale/space
requirements which are impossible to fulfill for the given number of
windows. It's better than displaying nothing, since it allows users to
move/close windows and restore this to a more usable state.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3730
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1685>
When creating an icon for the system actions search provider, set the
icon size using StIcons own icon-size property instead of ClutterActors
width and height property. That ensures the scale factor is applied and
the icon will be properly scaled on hiDPI screens.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1686>
The icon and close button might be overlapping the window actor but
were not considered in has_overlaps() which gets used to decide whether
to offscreen the actor for transparency. Since currently the icon is
visible when the preview is dragged and the whole actor is turned
transparent, the opacity will not be applied to everything as a whole
but the child actors individually. This leads to the window becoming
visible behind the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1684>
Calling startTouchGesture() on the workspacesViews can change the
visibility of the workspaces if not all of them are already shown, such
as when there are more than 3 workspaces or for 3 workspaces if we are
not on the central one. This invalidates the allocation and the width
used as distance for the gesture would become 0, resulting in drag
gestures immediately jumping to the first or last workspace due to a
division by 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3721
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1682>
Checking whether the item is empty is now the history’s job, per the
previous two commits. The history also trims the input for us.
The effect of this is that we call _history.addItem(), and thereby move
to the end of the history, even if the input is empty (or consists only
of whitespace); clearing the input field and pressing Enter becomes a
quick way to jump back to the end of the history. (The current history
item is not overwritten if the input is empty.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1653>
Scaling the icons all the way from/to 0 is a relatively big transition,
which is fairly distracting when playing simultaneously for multiple
previews after reaching the WINDOW_PICKER state.
Instead, tie the scale to the overview state itself, so that the animations
runs in parallel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1654>
Back when the Dash was vertical, the size of each item was calculated
solely based on the available height. After making the Dash horizontal,
this was swapped by the available width. However, when the height of the
Dash decreases, the current code results in never scaling them up ever
again.
Fix that by making ControlsManagerLayout explicitly pass the maximum Dash
sizes. Remove the 'notify::width' handler that served the same purpose.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1638>
Remove the dummy applications page that was introduced as a temporary
step. Replace the 'page-changed' and 'page-empty' signals with a 'search-active'
boolean property.
Remove ViewSelector.ViewsPage since it's now unused, and all the page handling
mechanism. At last, since we don't use any ShellStack features anymore, simply
make it a St.Widget with a ClutterBinLayout as the layout manager.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1667>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
On my local jhbuild setup some local stuff is not set up and
there's no pictures folder. This fixes a regression where it
blew up instead of saving to the home dir in this situation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
In addition to disabling the overlay when the state is not 1,
disable it also when not in the active workspace.
Make the Workspace class track the workspace's active state,
and resync the overlays when it changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The behavior of workspaces is different depending on whether
the overview is in window picker state, or app grid state.
When in window picker state, clicking on adjacent workspaces
should only activate them, without hiding the overview; and
clicking on the active workspace hides the overview. When in
app grid state, clicking on a workspace must always hide the
overview.
Pass the overview adjustment to Workspace, and leave overview
if the overview state is bigger than WINDOW_PICKER.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1645>
The overview transition consists of getting the initial and final
states of the overview adjustment, derivating various other internal
states from them (such as the fit mode, opacities, translations, etc),
and finally interpolating the allocation boxes.
When interpolating between the fit mode, WorkspacesView uses the current
allocation box to derivate the SINGLE and ALL fit mode boxes. However,
that creates a curved path during overview transitions. What we really
want to do here is calculate the fit mode box relative to the corresponding
overview state. For example:
+----------------+----------+------------------------+
| Overview State | Fit Mode | Workspaces geometry |
+----------------+----------+------------------------+
| HIDDEN | SINGLE | Cover entire screen |
| WINDOW PICKER | SINGLE | Between minimap & Dash |
| APP GRID | ALL | 15% screen height |
+----------------+----------+------------------------+
Using the table above as the reference, when the overview transitions
between WINDOW PICKER and APP GRID, we must interpolate between
(SINGLE fit mode @ between minimap & Dash) and (ALL fit mode @ 15% screen
height). That way, we always interpolate the final boxes, which corrects
the odd path that workspaces follow during this transition.
Make the WorkspacesView of the primary monitor use these cached boxes
when the overview is in the middle of a transition, and the fit modes of
the initial and final state differ, to calculate the workspaces positions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
It makes more sense in a spatial overview that the app grid
comes and goes to somewhere in the screen, instead of fading
in and out into the void.
Make the app grid rise from the bottom of the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Move AppDisplay, WorkspacesDisplay, and ThumbnailsBox from ViewSelector to
ControlsManager. This allows to always allocate the correct size for AppDisplay,
and will enable for a plethora of further improvements. The end goal is to
completely remove ViewSelector, and let ControlsManager handle the layout of
everything that's visible in the overview.
For now, replace the apps page with a dummy actor in ViewSelector.
Adjust various callers around the codebase to not access the ViewSelector
directly from the overview anymore.
Bind the opacity of the primary workspace to WorkspaceDisplay's opacity. This
allows removing the parent opacity hack in place, which will be done by the
next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Now that Overview is able to ease into any state, be it window
picker or app grid, we can move this ViewSelector method to
Overview itself, which is its rightful place to live.
Remove ViewSelector.showApps(), and make all callers call
Main.overview.show(ControlsState.APP_GRID). Also make sure the
show apps button is correctly toggled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Next commits will requires ControlsManager to animate to different
states, depending on how Overview is called. Add a new 'state'
parameter to ControlsManager's, and OverviewActor's animateToOverview,
and Overview.show().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Remove Workspace.zoomTo/FromOverview(), they're unused now. Rename
everything up to ControlsManager to prepareToEnter/LeaveOverview(),
since these classes don't run the animation anymore.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
WorkspacesView uses the floating layout when the overview is in window
picker mode, and the session layout when the overview is in app grid
mode. Up until now, the fit mode adjustment was used to derive the
workspace mode, but it is incomplete as it doesn't have the full range
of workspace states.
Make ViewSelector cascade the overview adjustment to WorkspacesDisplay,
and use the overview adjustment itself to derive the workspace mode.
Extra workspaces don't have to account for the fit mode, and thus are
basically a clamp(state, 0, 1) of the overview state. However, don't
call animateTo/FromOverview() anymore, since they ease the workspace
mode adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Boy, does this commit feel good.
While the workspaces view on the primary monitor *appears* as part of
the overall overview hierarchy, this hasn't actually been the case
until now. We synchronized its size and (stage) position to match
the workspaces display, but actually kept in a separate layer for
the transitions to and from the overview.
But now that the new layout manager slides out completely during the
overview transitions, the workspaces display starts out covering the
entire work area, which is exactly what we need for the transition.
So finally stop faking it, and actually make the primary workspaces
view a child of the workspaces display.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of delegating it to ViewSelector, make the transition to and from
overview ease the main state adjustment.
This commit temporarily breaks these animations, but on the other hand
introduces an important feature: ViewSelector is always allocated to the
actual size. This will finally allow for adding WorkspacesView as a child
of WorkspacesDisplay, and finally remove the actual geometry hack, which
is what next commit is about.
This commit also effectively reverts b64103efc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Instead of directly accessing ViewSelector and calling these methods
there, cascade the calls to OverviewActor, ControlsManager, and finally
ViewSelector. Also move the opacity transition to OverviewActor.
This commit has no functional change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, ActivitiesContainer reacts to showAppsButton and
transitions between app grid and window picking states on
its own. In the future, we want full control over this.
ControlsManager already has a state adjustment that represents
all possible overview states. Propagate this adjustment up to
ActivitiesContainer, and use it to drive the transition.
This requires moving the callback to the showAppsButton to
ControlsManager, since now it control the state adjustment
itself, not ActivitiesContainer's adjustment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
In the future, we want to tightly control the state of the
layout throught gestures, which requires hooking everything
together with adjustments. This is the first step in this
direction.
Add a new custom layout manager for ControlsManager that
allocates the search entry, the view selector, and the Dash,
vertically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1624>
Currently, gnome-shell uses the wrong scrolling direction for
horizontal scrolling events.
When dx < 0 for a smooth scroll event, then the scrolling direction is
supposed to be Clutter.ScrollDirection.LEFT, instead of
Clutter.ScrollDirection.RIGHT, as dx is smaller than 0.
Fix this issue by swapping the values LEFT and RIGHT.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1665>
It is possible for an initiated session to complete without
a request if polkit can authenticate the action without user
input. We fail to clean up after ourselves in that case, as
the cleanup is done after the dialog is closed.
The dialog can still be shown when the code that hides existing
dialogs while the screen is locked shows it on unlock. But as
the session was closed, the dialog is now defunct and cannot
be dismissed by the user.
Fix this by running the cleanup on close() when the dialog
wasn't shown.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3701
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1662>
The children variable holds the icons that were originally in
the dash. For the separator visibility, we should consider the
icons that are in the dash after the update, so we must consider
additions as well as removals.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1659>
Previously we used a bunch of heuristics for this. We checked if velocity
was directed towards the nearest snap point and its value was larger than
a threshold. If it is, we completed the swipe, otherwise we cancelled it.
This was good enough at the time, because this code was originally written
for back/forward swipe. Since then, the swipe tracker was extended to
handle arbitrary snap points and not just 0 and 1, or -1 and 0, depending
on text direction. After that it was iterated on, but never significantly
redone.
This worked well enough, but had two problems:
1. In some cases, notably overview, it may be wanted to be able to swipe
through multiple pages at once. This wasn't really possible because we
always picked the adjacent snap point.
2. Since we can't do that well, we want to restrict swipes to one page at a
time. It was done in a rather hacky way by clamping the position into
[-1, 1] range from the place where we started the swipe. This works
if we start the swipe from idle position, but if an animation was
already going, the range would be clamped to arbitrary values, and very
likely containing only one snap point, which we already swiped past at
this point. In this case, finishing the swipe would cancel it regardless
of velocity. This means that if one tries to quickly move through
carousel pages via swiping, half of the swipes will be inexplicably
cancelled.
We'll use the deceleration formula from
https://medium.com/@esskeetit/how-uiscrollview-works-e418adc47060#10ce
to calculate then projection point, then pick the nearest snap point and
calculate the duration as we did before. It works well enough for short
distances, but has two problems:
1. It caps the maximum distance at a pretty low value - about 5 pages in my
testing.
2. With how we pick the nearest snap point, it's too easy to accidentally
cancel the swipe,
To combat the first problem, we can modify the curve: only use linear
function at small distances, and smoothly transition it to a parabola
further.
For the second problem we can add two special cases: first, if the swipe
ended up between the initial snap point and the next one, we always prefer
the latter. Second, a good old velocity threshold for cancelling.
We'll also use a slightly smaller deceleration value for touchpad: 0.997
instead of 0.998.
Now that we can pick any snap point, the [-1, 1] clamping doesn't make
sense anymore, so instead let's replace it with a more flexible
mechanism: if we're near a snap point, pick its adjacent snap points.
Otherwise, take the two nearest snap points, and take their adjacent
snap points. This way we have 3 snap points to choose from when
starting a swipe from an idle position, and 4 if we start during an
ongoing transition.
This way, if we've just swiped from snap point n to n+1, the transition
will pick snap points n-1, n, n+1, n+2 and if we swipe again, we will
likely land on n+2. During that transition, if we swipe again, it will
likely have already passed the snap point n+1, so this time the available
snap points will be n, n+1, n+2, n+3, so we can swipe again and it will
still complete, and so on.
This will make it easy to allow multi-page swipes as well, by just
removing the clamping.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
In some cases we may get anevent with very low delta at the end of the
swipe. While we can't completely ignore them, we can smooth them using a
scroll history, similarly to what GTK kinetic scrolling does: keep track
of the last 150ms of events, and sum their deltas when calculating the
velocity.
The logic is based on what GTK does in GtkGestureSwipe and
GtkEventControllerScroll.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1647>
Let empty input result in an error, just like other invalid commands
(bad syntax, nonempty whitespace, etc.). GLib already has an error
message “Text was empty (or contained only whitespace)” which it shows
for whitespace-only input, so letting that message apply also to empty
input makes sense.
This requires some tweaks further down the file to avoid interpreting
empty input as an empty path (relative to the home directory) and then
opening the home directory.
Part of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3183.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1442>
Resource icons are added to the fallback icon theme, so they won't
get used if a matching icon is found in the configured theme.
That includes fallback names, so Adwaita's "window-close-symbolic"
takes precedence over "window-close-24-symbolic" in hicolor.
Fix this by using a custom name for a custom icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1640>
The Message class this is derived from unconditionally adds a close
button with 0 opacity that only gets shown on hover for messages that
can actually be closed. The MPRIS MediaMessage however can never be
closed and having a close button can cause the title to be cut short
unexpectedly.
Similarly the secondary text which other notifications use to display
the notification time is always left empty here as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3664
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1632>
grabHelper is passing a boolean argument to onUngrab() callback function
and since commit 1acbdcc9b3 we'd end up adding it to to the callback list or
we'd try to invoke it:
(gnome-shell:3490851): Gjs-CRITICAL **: 17:19:20.460: JS ERROR:
TypeError: func is not a function
onComplete/<@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:56
onComplete@/media/M2/GNOME/gnome-shell/js/ui/appDisplay.js:2407:40
_makeEaseCallback/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:85:13
_easeActor/<@/media/M2/GNOME/gnome-shell/js/ui/environment.js:170:64
Use an arrow function so that we can control the parameters we pass
to popdown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1635>
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
So far, we couldn't allow workspace scrolling outside the overview
because scroll events were always sent to clients. However mutter
was changed recently to pass on scroll events when the mouse button
modifier (usually super) is pressed, which allows us to enable the
same workspace scrolling as in the overview now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The design now calls for super-scroll for workspace switching
in the session, however it is currently only possible for
SwipeTracker to either handle scroll events or not.
In order to support the new use case, add a new :scroll-modifiers
property that allows specifying modifiers for which scroll events
are handled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1612>
The code to update the actor position based on the cursor and current
scale was run in a 'new-frame' handler. This is working fine when
animations are enabled, but when they are turned off this does not work.
This is because the 'new-frame' signal is emitted before the changes for
that frame are applied. So with animations off the position was only
ever updated with the starting values. As a result the shrunk actor was
not being dragged by the position where it was clicked, but by where it
was clicked in the original size, which is likely not even on the shrunk
actor.
This change now also updates the position in the onComplete handler
which gets run with the final scale, even if the duration is 0.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1627>
Next commit will bind the workspace state adjustment to the snap
adjustment in WorkspacesView, and we'll need the preparation
steps but not the easing of the state adjustment.
Split preparation steps from zoomFromOverview() into a new method
prepareToLeaveOverview().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
As per the latest mockups, then horizontally snapping, the active
workspace should be highlighted. Because WorkspacesView clips to
allocation, we cannot simply scale up the active one. Instead,
scale down the inactive ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Synchronizing the actual geometry while animating from / to the overview can
break the animation. Let's prevent that. This code will go away soon anyway,
but to not lose bisectability, it's better not to leave it misbehaving until
then.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
When vertically snapping, WorkspacesView currently allocates workspaces
side-by-side, then applies an extra step of translation to center to
the active workspace. This extra step, however, gets in our way because
now we need tighter control of the workspaces positions in allocation,
in order to properly interpolate them.
Move the translation of workspaces to the allocation code itself, and
remove the extra translation step.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Currently, WorkspacesView positions each workspace on a
per-page layout, each page with the allocated width and
height of WorkspaceView. This layout doesn't work well
with horizontal workspaces.
Layout workspaces side by side, instead of per page. The
layout is influenced by a "fit mode", which reflects the
different behaviors exposed in the mockup. This fit mode
represents whether a single or all workspaces will fit
available geometry.
The single fit mode is always used for now. Next commits
will make it switch to the all fit mode when in the app
grid state.
The translation_{x,y} also needed to reflect the switch to
a side-by-side layout, and use the geometry of the workspaces
to determine the offset. Notice that, when the fit mode is ALL,
there's no translation applied.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1613>
Nowadays gjs allows to omit get/set accessors for read-write properties,
and will define reasonable defaults in that case. In many cases we don't
need anything more than the default handling, let gjs handle those props.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1611>
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
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
IconGridLayout is a new layout manager that aims to replace the
current paginated layout algorithm implemented by the icon grid.
There are a few outstanding aspects of this new layout manager
that are worth highlighting. IconGridLayout implements all the
mechanisms necessary for a paginated icon grid, but doesn't
implement any policies around it. The reason behind this decision
is that this layout manager will be used by other places (e.g.
the login dialog) that demand different policies to how the
grid should look like.
Another important aspect of this grid is that it does not queue
any relayouts when changing its properties. If a relayout is
required, the actor should manually queue it. This is necessary
to avoid layout loops.
Add the IconGridLayout class. Next commits will do the surgery
to IconGrid and any related code to use this new layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1271
For drag actors which get reparented to the uiGroup, we currently wait
until the next input event to set the fixed position of the actor, until
that they will just be allocated their old fixed position, which is 0,
0.
So avoid drag actors flickering at the top left for one frame and
position them correctly right after reparenting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly adjust for drag actors which were allocated using a custom
vfunc_allocate() and might not have gotten allocated their preferred
size. When DND reparents the actor to the uiGroup, the drag actor will
get allocated its preferred size, so we also need to take the difference
between the old allocation size and the preferred size into account
before reparenting to the uiGroup.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
Properly handle drag actors which are not allocated using a fixed
position and disable the fixed position we were using to move the actor
around before we reparent it again to its original parent.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1310
The workspace.js file is quite large and is a bit confusing when it
comes to the term "window" in there, because it can either refer to a
WindowPreview of a complete window or to an individual window like an
attached dialog.
So try to avoid that confusion and split the new WindowPreview class and
its WindowPreviewLayout layout manager out into a new windowPreview.js
file.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
MetaWindow is Mutters representation of a window and provides all the
APIs about it, MetaWindowActor is just the ClutterActor that's drawing
that window. So use a MetaWindow to create a WindowPreview instead of
the window actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We want to stop using the MetaWindowActor for things which are actually
related to the MetaWindow, one more thing where we can change that is
the overviewHint, which is currently added to the MetaWindowActor.
So move that hint to the MetaWindow and stop calling
get_compositor_private() in a few more places.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We can simply get the MetaWindowActor by calling
MetaWindow.get_compositor_private(), so stop accessing the realWindow
property of WindowPreview. For this we also have to make _isMyWindow()
and _isOverviewWindow() take a MetaWindow as an argument instead of a
MetaWindowActor.
Since the WorkspacesThumbnails are also drop targets for WindowPreviews
and their WindowClones also have the public metaWindow property, switch
to using the metaWindow property there, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since the WindowPreview class rarely needs to handle the actual actor
painting the window preview, refactor the WindowPreviewLayout a bit to
only pass a MetaWindow to its addWindow() and removeWindow() functions.
Also make the getWindows() function return an array of MetaWindows,
which makes the getMetaWindow() function obsolete, so remove that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
We're going to remove ClutterClones, so call the parameters to
addWindow() and removeWindow() "actor" instead of "clone". Also make the
destroyIds less confusing and rename the actual actor destroy id to
"destroyId", and rename the window actors destroy id to
"windowActorDestroyId".
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Since ClutterClones are going to be removed, let's switch the
terminology here to something that's more understandable and rename the
WindowClone class and its layout manager to
WindowPreview/WindowPreviewLayout.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1307
Now that we properly notify mutter about when a size-change animation
has ended, it should never happen that a new size-change animation is
started without the last one being cancelled (ie. 'kill-window-effects'
being emitted).
This means there should also never be an old animationInfo attached to a
window actor, so warn in case we still find one when starting the
animation.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
We're currently using the hack of telling mutter that our effect is
completed (even though it isn't) in order to unfreeze updates of the
window actor.
This causes a bug with detecting the wl_outputs a window is
visible on, because the MetaWindowActor emits its "effects-completed"
signal too early, making Mutter update the wl_outputs while we're doing
the animation.
Now since meta_wayland_actor_surface_is_on_logical_monitor() uses the
transformed position and size of the MetaSurfaceActor and is being
called right after we setup the animation (but before it actually
starts, that happens at the next paint cycle) it will use a "very wrong"
rectangle: The transformation has been set to move the actor back to its
old position, and while we did already unfreeze updates and called
clutter_actor_set_position() in meta_window_actor_sync_actor_geometry(),
the actual allocation is not updated yet; this makes
clutter_actor_get_transformed_position() return a position including in
the new transformation, but not including the new allocation, and the
rectangle ends up being moved to the next monitor or completely out of
the stage.
To fix this issue properly, we need to decouple unfreezing actor updates
from emitting the "effects-completed" signal, which is now possible with
the new meta_window_actor_freeze() and meta_window_actor_thaw() APIs. So
use those new methods to freeze and thaw actor updates ourselves and
make sure to call shellwm.completed_size_change() only after the
animation has finished.
Mutter MR: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/513https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
It might be that we receive a "kill-window-effects" signal between the
emission of the "size-change" and the "size-changed" signal.
In this case we already have the animationInfo attached to the window
actor, so we should also remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1251
Using CSS to center the title actor on the border is a bit ugly, because
it requires the CSS to match the calculations used in chromeHeights().
Also it is not possible to use CSS margins for cases where the position
of the actor is determined at run time, such as for the close button.
Instead use an invisible actor that spans between the horizontal and
vertical center lines of the border as guide when aligning the title
actor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1313
Commit 1ea22a5281 broke the window reposition animation when it
based the ::size-changed signal on the layout manager's bounding box
instead of the MetaWindow::size-changed signal.
That's happening because of the combination of:
1. we adjust to window size changes immediately without animations
2. closing a window triggers a change to a 0x0 bounding box which
is not treated as a size change
Fix this by addressing the 2nd factor, and don't treat a change to
a 0x0 bounding box as size change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2901
Animating the window clones of the overview requires the fullGeometry
and the actualGeometry to be set, which they won't be when showing the
overview for the first time. So don't even try to animate the window
clones in that case because the geometries will still be null and
accessing them in workspace.js will throw errors.
The workspace views will still get the correct layout as soon as the
allocations happen because syncing the geometries will trigger updating
the window positions. Since animations are disabled for position changes
when syncing the geometry though, we won't get an animation and the
clones will jump into place. That's not a regression though since before
this change we also didn't animate in that case because the geometries
used were simply wrong (the actualGeometry was 0-sized as explained in
the last commit).
If we wanted to fix the initial animation of the overview, we'd have to
always enable animations of the window clones when syncing geometries,
but that would break the animation of the workspace when hovering the
workspaceThumbnail slider, because right now those animations are "glued
together" using the actualGeometry, so they would get out of sync.
The reason there are no errors happening in workspace.js with the
existing code is that due to a bug in Clutter the fullGeometry of
WorkspacesDisplay gets set very early while mapping the WorkspacesViews
(because the overviews ControlsManager gets an allocation during the
resource scale calculation of a ClutterClone, see
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181), so it
won't be set to null anymore when calling
WorkspacesView.animateToOverview().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
The fullGeometry and the actualGeometry of the WorkspacesDisplay are set
from the allocation of the overviews ControlsManager and the
WorkspacesDisplay, that means they're only valid after those actors got
their allocations during Clutters allocation cycle.
Since WorkspacesDisplay._updateWorkspacesViews() is already called while
showing/mapping the WorkspacesDisplay, that allocation cycle didn't
happen yet and we end up either setting the geometries of the views to
null (in case of the fullGeometry) or to something wrong (a 0-sized
allocation in case of the actualGeometry).
So avoid setting invalid geometries on the views by initializing both
the fullGeometry and the actualGeometry to null, and then only updating
the geometries of the views after they're set to a correct value.
Note that this means we won't correctly animate the overview the first
time we open it since the animation depends on the geometries being set,
but is being started from show(), which means no allocations have
happened yet. In practice this introduces no regression though since
before this change we simply used incorrect geometries (see the 0-sized
allocation mentioned above) on the initial opening and the animation
didn't work either.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119
Start using the new overlays we introduced in the last commit and remove
the WindowOverlay class and the objects for keeping track of them in the
Workspace.
The new layout which doesn't use the -shell-close-overlap CSS property
anymore sligthly changes the position of the close button to be a bit
further away from the actual window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
So far we allowed the titles of window overlays to expand their width to
be larger than the actual WindowClone, they could expand to the full
size of the Workspace.
Since we're now going to implement those titles as part of the
WindowClone itself, having this feature is no longer possible as easily
as it was before. That's because the clones are stacked according to the
stacking of the actual windows, and since the overlay-elements are
attached to those clones, they will also be shown underneath other
clones.
So stop allowing the titles to expand and limit their size to the width
of the clone, which makes sure titles never get shown above or
underneath other clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Add the window overlays we're currently showing using the WindowOverlay
class to the WindowClone class and implement them using
ClutterConstraints instead of the old fixed position/size layout, which
had to be used because the workspaces were scaled, and the title and app
icon were kept unscaled using a separate layer.
Specifically, this is done by adding the ClutterClones to a static
container owned by the WindowClone and adding the elements of the
overlay as children to the WindowClone itself. That way the
overlay-elements can use the container as a source for their constraints
and we avoid having to make sure the overlays remain visible above the
ClutterClones.
We're not using the new overlays yet, they're hidden by default and
showOverlay() isn't called anywhere yet.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that we have a new API to get all the windows and metaWindows from
our layout manager, implement the deleteAll() method of the window clone
using that API instead of looping through the children of the actor and
using the source of the ClutterClone.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1298
Now that the folder dialog covers the whole primary
monitor, it eats all input events, and doesn't allow
the event blocker to detect clicks.
Move the click action to the folder dialog itself, and
popdown the dialog if a click is triggered on the dialog
(but not on any children).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Future commits will improve input handling of the folder
dialog, and they'll require the dialog to cover the whole
primary monitor.
Add another internal, center-aligned container to the
folder dialog, and make it cover the whole available area.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Right now, the app folder dialog isn't really a dialog,
since it is actually added to the AppDisplay. Furthermore,
having it added in AppDisplay may mess up with its sizing
calculations, since AppDisplay has a ClutterBinLayout and
the folder dialog has a fairly large minimum size.
Add the folder dialog to the overview group. Next commits
will adjust various actors to be able to better handle it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1301
Events have a clear and obvious connection to the calendar, and similar
to the Clocks and Weather sections there's a strong link to a particular
application.
Adding them as another section to the right-hand side of the calendar
therefore presents a viable alternative to the old events section.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
The idea behind hiding the notifications and media section on days
other than today was that they represent present activity together
with today's events, in contrast to past and future events from
other days.
After events were moved out of the message list, that behavior is
no longer useful: We just guarantee that the left-hand side of the
calendar will always be empty when browsing the calendar.
Adjust to that by removing the limitation by date.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
While treating notifications as a type of present event was a neat
concept, there are some issues with it that we never managed to
address (not least the inability to "open" an event).
So remove the current events section from the message list; we'll
bring back events in a different form later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1282
This comment is no longer correct, we're not inserting any actors here
to adjust for the window border, but we're modifying the allocation of
the children to adjust for that border.
Since that happens in the layout manager anyway, remove the comment
here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Now that we handle all ClutterClones belonging to the WindowClone pretty
much the same, we can add a generic _addWindow function to WindowClone
which creates the ClutterClone and adds it to the layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
This isn't quite the same as the allocation, but it's what the workspace
actually wants to use given that we use the bounding box of the
WindowClone for all the layout calculation.
So instead of calculating the windowCenter in the WindowClone, make use
of the bounding-box property of the layout manager and return the center
point of that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Make use of the new bounding-box property we introduced for the
WindowClones layout manager in the last commit.
With this we can remove all the bounding box calculation code from the
WindowClone class and simply use the "notify::bounding-box" signal to
notify changes to our size. To make sure users of the WindowClone don't
break, we now have to convert the layout managers ClutterActorBox in our
getter function to a JS object.
Since we now also don't have to connect to the "destroy" signal of the
attached dialogs anymore, we can remove _disconnectSignals() and only
listen to "destroy" of the toplevel window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
Move the tracking of the bounding box and all the layout related things
out of the WindowClone class and into the layout manager. This allows
the layout manager to keep track of its windows itself and simply notify
the new bounding-box property in case that box changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1297
WorkspacesDisplay is a ClutterActor subclass, and overriding
the show and hide methods require chaining up, otherwise the
actor isn't actually shown or hidden.
To avoid clashing with the pre-existing show method, rename
to animateToOverview.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1295
Unlike the desktop-entry hint, the app name is not optional. That
doesn't mean that we'll be able to match it to a .desktop file,
but we can at least try if we fail to match on PID or desktop-entry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1291
Since we now have a layout manager for the WindowClone that allows
allocating it a size that isn't the absolute size of the window, we can
now give the WindowClone an artificial size and it will get scaled
accordingly.
So make use of that and stop positioning WindowClones using fixed
position and scale and use a fixed position and fixed size instead. This
will make it easier to use a ClutterLayoutManager to allocate the
WindowClones, because layout managers should only set the allocation of
their children, not the scale.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Since we're going to override the fixed width and height of the
ClutterActor the WindowClone is subclassing, remove those confusing
getter methods for width and height and switch to the public boundingBox
for getting that information.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
The getOriginalPosition() API of WindowClone can easily be replaced by
using the existing boundingBox property, which reflects the windows
bounding box in absolute coordinates. This property is also used
everywhere else in the Workspace object, so we can use it here, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Change the preferred size functions of the layout manager of window
clones to allow allocating smaller sizes, too. Also scale down the
allocation sizes of the ClutterClones our allocate implementation so
the ClutterClones will scale their texture accordingly.
This will enable us to position the window clones using their allocation
size instead of their scale, which is necessary when introducing a new
ClutterLayoutManager that positions the window clones.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
We're going to add a ClutterLayoutManager responsible for allocating the
WindowClones. Since layout managers should only set the allocation of
actors, not the translation or scale, we need to position the
WindowClones using their x, y, width and height properties.
The first step for this is to revert this commit, which switched from
setting fixed positions on WindowClones to using the translation
properties.
This reverts commit 8929c89d1f.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1294
Being able to visualize the actor tree is a handy feature
to have, specially when debugging the hierarchy.
Add a new "Actors" tab to the Looking Glass with the actor
tree inspector. The tree is cleared on unmap to not get
heavy on the number of actors.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1292
As explained in the comment in _init() of WindowClone, we hide the
actual clone from picking so it doesn't interfere with XDND.
This description applies to the clones of the attached dialogs just as
well though, so hide the clones of attached dialogs from picking, too.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1293
We currently only remove the screenshot operation from the shooter
map if the color pick operation completed successfully, but not if
it was cancelled. As a result, we now reject any further requests
from the same sender because we assume that there is an ongoing
operation.
Fix this by moving the cleanup to a finally clause that runs for
both code paths.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Right now _createScreenshot() returns a tuple that indicates failure
when a sender requests a screenshot operation before a previously
started operation finished.
However that doesn't work for the PickColor() method, as it uses a
different return type than the other methods.
Address this by returning an error instead, which works in any case;
arguably trying to start multiple operations in parallel is an error
by the caller more than it is a failed operation anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1288
Now that the only user of the IconGrid is AppDisplay, and
it only uses the paginated icon grid, there's no point in
having the two classes split anymore.
In addition to that, future commits will introduce a layout
manager that will extend current icon grid features, and
merging PaginatedIconGrid and IconGrid in the same class will
vastly simplify this transition.
Merge PaginatedIconGrid into IconGrid, and adapt AppDisplay
to this change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1267
Now that AllView is the only actor that AppDisplay creates,
we can actually merge them together.
Merge AllView in AppDisplay, remove what used to be AppDisplay,
and rename AllView to AppDisplay.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
The Frequent apps grid has a few problems:
* On a fresh install there would be no history of app usage so the
applications shown in the grid have no relevance it takes time
to be useful instead of being useful from the start;
* The grid has far too many items in it to be relevant; 24 apps is
well beyond the average use case as most people don't frequently
use that many, so it gets populated with several apps that are
single use (hello xterm);
* The position of items in the grid are always changing based on an
unknown frequency metric (and not by user-intended input) which
makes it a poor way to quickly launch apps as one would have to
constantly learn the positions of the items in the grid;
* Having two app grids is a bit superfluous and needlessly complicates
the app launching navigation: you have to spend time checking the
frequent grid and if it's not there you have to switch over to another
grid and find the app you need in there it's not straightforward.
Remove the Frequent tab and simplify the related code.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1425https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/880
With color picking implemented in the compositor, we
can do better than letting the user pick a pixel with
the crosshair cursor, and present them with a preview
of the color that will be selected.
Do this by replacing the cursor with a custom icon and
apply a recoloring effect, where we replace a given color
with the color of the currently hovered pixel (similar
to a green screen).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/451
logExtensionError() currently saves the error message by calling
toString() on the passed error. That's convenient as it allows to
pass a string instead of a "proper" error, but the result isn't
great for the common Error case: Its toString() method prefixes
the message with the error name, which usually is just "Error:".
The plain message is more suitable for displaying it to users,
so use that for Error objects.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2337
Replace the usage of IconGrid in the grid search results by
a custom layout manager that only allocates as many children
as the actor can fit.
This new layout manager does not implement changing the icon
size depending on the screen size.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1265
This is a small convenience method for using ClutterActor's iterator API
with javascript's built-in iterator protocol, for example as:
for (let child of container.iterate_children())
doStuff(child);
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1268
For fd.o notifications, we are taking the sender's PID into
account when associating notifications with sources (mainly
to deal with notify-send).
This broke when the implementation under the well-known name
was moved into a separate service, as the implementation in
gnome-shell will now always see the public notification-daemon
as sender.
Restore the old behavior by resolving the sender PID in the
separate service, and pass it as hint to the implementation
in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2592
Spidermonkey caches imports, which means that uninstalling an
old extension version and installing a new one doesn't work as
expected: If the previous version was loaded, then its code will
be imported instead.
For the last couple of releases this has been a reliable source
of extension bug reports after major GNOME updates. Thankfully
chrome-gnome-shell removed its update support in favor of our
built-in support now, but users may still use older versions
or perform those actions manually, so it still makes sense to
catch this case and set an appropriate error.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1248
The do-not-disturb button and the contained switch are
tied together via a bidirectional property binding.
However it still matters which objects are used as source
and target, as that will determine the initial state: Right
now the (unchecked) button is used as source, which means
that do-not-disturb is turned off on startup.
We want the state to be preserved, so swap source and target
to let the switch (that is bound to the underlying GSetting)
control the initial state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2804
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
Whether or not an extension has errors influences the 'canChange'
property, but so far we only update it for errors that occur when
initializing the extension, not when an extension is enabled later.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1249
Soup.SessionAsync by default sets timeout and idle_timeout to 0. This
causes connections to hang around in state CLOSE_WAIT forever after the
remote host has closed the connection.
To fix this, we could set timeout and idle_timeout manually. However,
Soup.SessionAsync is marked as deprecated anyway and should be replaced
by Soup.Session. Doing so also sets a default timeout of 60 seconds.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2774
Removing a stylesheet from the theme will trigger a style update. There's
little point in updating the extension actors that are about to be destroyed
(hopefully), so call the extension's disable() function first.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
Sometimes an MPRIS media player will create and then destroy an object
before the signals that handle the object's destruction can be created.
This verifies that the object still exists after the necessary signals
have been created.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2776
Since commit 0ecddafc20 gsd-xsettings startup has been made conditional
on the systemd user instance being available at runtime. While that is
correct, it means that completing xwayland startup is also conditional
now.
We always want xwayland startup to go ahead, so wait for the XSettings
plugin to appear on the bus when gsd-xsettings is launched by gnome-session
and complete the task immediately if startup fails.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1252
gjs has gotten less forgiving about missing getters/setters, and
commit 6aa1b817 missed the missing getter in the base policy class.
Most notifications use a policy subclass that already provides a
getter, but at least Main.notify() and friends don't; unbreak them
by fixing the base class.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1229
When a modal that's not on top of the modalActorFocusStack gets popped,
we shift the focus stack as described in popModal() to ensure the chain
remains correct. That however destroys the association of a modal actor
and its prevFocus actor on the focus stack, because the prevFocus actors
are now moved to different entries of the stack.
Now when a prevFocus actor gets destroyed, we don't handle that case
correctly and search for the modal actor that was associated with the
prevFocus actor before the stack was shifted, which means we end up
unsetting the wrong prevFocus actor.
So fix that and search the stack for the prevFocus actor which is being
destroyed instead to unset the correct entry.
Thanks to Florian Müllner for figuring out the actual issue and
proposing this fix.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2446
The workspace switcher blocks state updates while the indicator is
animating. Since commit 9c1940ef9d the indicator is considered to
be animating when the workspace adjustment's value doesn't equal the
active workspace.
There is one case though where this breaks badly: When a workspace
is inserted before the active one, the adjustment's upper and value
properties are changed without transitions. But if that change happens
while there's an ongoing transition to the previously active workspace,
the value gets out of sync with the active workspace and we end up
blocking state updates indefinitely.
Fix this by removing any transitions before setting the adjustment
value.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2625
We override the :visible property for the keyboard actor, but don't
provide a corresponding setter. The property is therefore read-only
on the javascript level, and any attempt to set it will fail.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2691
Just as with the last commit, we should not break the assumption made by
Clutter that parents have their allocation set before their children get
allocated, so fix that here, too.
In this case we have to fix it by chaining up to the parent vfunc
override and updating the allocation once more before allocating the
`this._label` child.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
It's important to update the allocation of the parent before allocating
its children, it's an assumption we make in a lot of places.
This broke resource scale calculation for boxpointers and their
children when multiple monitors with different scales are used and the
primary monitor is not positioned at x=0, y=0.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1615
The session mode determines whether the screen casting should work or
not, but until now only dealt with the built in screen cast, not the
ones using PipeWire. Add the newly added API for inhibiting remote
access when the session mode says screencasts are not allowed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210
As of mozjs68 (gjs-1.64) `globalThis` is recommended over `window` and
it makes more sense in this context anyways. Migrate the few instances
of `window` we use and adjust the eslint configuration.
`window` will continue to resolve to `globalThis`, so this won't affect
extensions or other downstream users.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2322closes#2322
getEvents() filters all events for the given range and sorts the result.
That's more than we need when checking whether there are any events,
where we only care that there's at least one event in the range.
Address this by splitting out the event filtering into a generator
function, so hasEvents() can return after at most one iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
We track messages so that we can account for just added and removed
events instead of having to rebuild the entire list, however it's
also possible that the time or summary of an existing event changed.
Account for that by updating existing messages in-place.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1192
The additional function UnlockDialog.addCharacter() is only used at one
place, so we can simply remove it and call AuthPrompt.addCharacter()
directly. The AuthPrompt is shown right before that anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1209
Normally, we inhibit suspend while locking the screen. But in the
session mode used for gnome-initial-setup locking is not supported, so
in that case this inhibit call is pointless and should be avoided.
Without this patch you get the following error when you suspend and
resume during initial setup:
JS ERROR: Error getting systemd inhibitor: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation
inhibition has been requested for is already running
_promisify/proto[asyncFunc]/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:435:45
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
On Fedora 32 if you close the laptop lid during gnome-initial-setup,
gnome-shell hits this error:
JS ERROR: Exception in callback for signal: prepare-for-sleep: TypeError: this._dialog is undefined
_resetLockScreen@resource:///org/gnome/shell/ui/screenShield.js:434:9
activate@resource:///org/gnome/shell/ui/screenShield.js:571:14
lock@resource:///org/gnome/shell/ui/screenShield.js:617:14
_prepareForSleep@resource:///org/gnome/shell/ui/screenShield.js:219:22
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_prepareForSleep@resource:///org/gnome/shell/misc/loginManager.js:198:14
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:133:47
_convertToNativeSignal@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:169:19
This is because _ensureUnlockDialog() hit its first early return. So
return early from activate() in that case, so this._dialog doesn't get
used while it's null.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1213
StButton returns CLUTTER_EVENT_STOP in various circumstances, but
AppIcon throws that away and returns CLUTTER_EVENT_PROPAGATE even
when it should stop.
Return the parent class' result instead of CLUTTER_EVENT_PROPAGATE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1211
These properties are never written; in the base class they are always
their default values, and in the subclasses the getters are overridden.
This will be necessary because GJS is adding checks to make sure that
readable properties always have a getter, writable properties always
have a setter, and that the variations of camelCase/snake_case are
handled correctly. It's supposedly backwards compatible, but that
assumes that code is not doing things like forgetting a setter on a
writable property. (If the missing setter had ever been called, it might
have led to a crash, which is why we've made this change.)
This is the minimally invasive patch which should work with both older
and newer versions of GJS. If you decide to require GJS 1.65.2, then
you'll also be able to remove the getters from NotificationPolicy as
well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1205
When handing the resetDialog request we're leaving a source ID alive,
leading this error:
(gnome-shell:22464): GLib-CRITICAL **: 17:46:11.065: Source ID 12934 was not
found when attempting to remove it:
== Stack trace for context 0x55c9246916c0 ==
#0 55c9249151b8 i js/ui/components/polkitAgent.js:391 (11f71fd544c0 @ 100)
#1 7ffc55140aa0 b self-hosted:1009 (3062ba49af88 @ 423)
#2 55c924915120 i js/ui/modalDialog.js:167 (1c9e50ae9880 @ 62)
#3 55c924915098 i js/ui/modalDialog.js:186 (1c9e50ae9970 @ 12)
#4 55c924915008 i js/ui/environment.js:75 (1c9e50a8d5b0 @ 98)
#5 55c924914f78 i js/ui/environment.js:149 (1c9e50a8d9e8 @ 14)
So, reset the source handle to avoid trying to remove it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1203
Clutter.Animation doesn't contain any animation modes, they live in
Clutter.AnimationMode. The places we did `Clutter.Animation.WHATEVER`
just evaluated to `undefined`. Thus, use the correct namespace for the
animation mode enums.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1199
Translations are provided by .directory files, so trying to look
up a category name without the suffix will always fail.
Commit 343b3351f1 tried to fix this previously by changing the
saved keys, but that broke existing translatable folders.
Appending the .directory suffix for the lookup instead fixes the
issue without regressing non-custom folders.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2623
Right now, the actor hierarchy is such that the scroll view
does not contain the actual grid. It looks as follows:
StScrollView
↓
StBoxLayout
↓
ShellStack
↓ ↓
PaginatedIconGrid StWidget
This hierarchy can be slightly reorganized by changing it to be as
follows:
ShellStack
↓ ↓
StScrollView StWidget
↓
StBoxLayout
↓
PaginatedIconGrid
This will simplify future work where the PaginatedIconGrid will be
an implementation of StScrollable, in which case we'll be able to
simply remove the StBoxLayout from there.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1191
If a search provider is installed by an app which is blacklisted for the
current user by their parental controls, don’t show it or results for
it.
Currently, this only filters ‘remote’ (not built-in to the shell) search
providers. This seems fine for now; in future it could be expanded to
also filter built-in search providers, if any of them end up needing to
be filtered.
No corresponding changes need to be made `remoteSearch.js`, because the
results of `loadRemoteSearchProviders()` are filtered in `search.js`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
Filter the apps shown on the desktop and in search results according to
whether they are blacklisted by the user’s parental controls.
This supports dynamically updating the filter during the user’s session.
This adds an optional dependency on libmalcontent. If that’s unavailable, no
parental controls filtering will occur.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/465
While we now deal more gracefully with adapter removals, we can
still mess up the hadSetupDevices tracking:
As adapters become available before any devices, we'll always
reset the setting to false when Bluetooth is turned on. And if
no set up device happens to be in range, it will still be false
when Bluetooth is turned off again.
To address that, only update the setting if we have an adapter
(like we do now) and we had one before (so it wasn't the adapter
itself that changed).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Our intended behavior when bluetooth is turned off is to keep
the menu visible if devices had been set up previously.
However since gnome-bluetooth@c437c729, devices are removed
first before removing the default adapter, so we now end up
always setting the property to false before checking for it.
Fix this by deferring all model changes to an idle, so that
we can process them as a unit. Do the same for proxy property
changes, as those may trigger a row-removal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Since commit 26c2cb9f65, nDevices is always the actual number of
paired/trusted devices. So when bluetooth is turned off, it is
now 0 rather than forced to 1 if devices were set up previously.
Fix this by checking the property that tracks set up devices instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Pretty much the same case of the previous commit: we want this size
to be scale-dependant, and using the width and height properties of
ClutterActor doesn't automatically update.
Use CSS to set the width and height.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
The return value of st_theme_node_lookup_length() is scaled according
to the scale factor. IconGrid.ICON_SIZE is not. However, when BaseIcon
tries to fetch the CSS value for "icon-size" (which returns a scaled
value), it uses it as-is, mixing the two coordinate systems.
Use a single coordinate system (unscaled sizes) in IconGrid.BaseIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1175
Usually the screen is woken up before the shield is deactivated, but
it is also possible to unlock the session programmatically via the
org.gnome.ScreenSaver D-Bus API.
The intention is very likely not to unlock a turned off screen in
that case. Nor does it seem like a good idea to change the lock
state without any indication.
Waking up the screen is more likely to meet expectations and is
more reasonable too, so do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1158
Extension that want to expose their own preferences (for example as menu
items) do that by passing their UUID to gnome-shell-extension-prefs.
But since 3.36.1 the app is optional and no longer accepts arguments on
the command line. To adjust, extensions now need to make a D-Bus call
the extensions portal, just like the app and gnome-shell.
We will add a convenience method for that purpose, so it makes
sense to share the existing code. As it's extension-related, the
extension manager looks like the right place ...
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1163
A promisified method expects the callback parameter to be either
a function (in which case the original method is called normally)
or omitted altogether (in which case a Promise is returned).
The call to open application details in Software does neither and
passes null instead, which will result in a warning (because no
function argument means a promise will be used, but not omitting
the parameter means we end up with too many arguments).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2551
In case where only one device is connected, we want to display its name
in the menu. For that we will need more than the number of known/connected
devices, so change the function to return an array of device infos instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2340
During the shell initialization we call the (deprecated) function to
override the Desktop environment in Gio DesktopAppInfo to make sure that
applications are correctly shown (as per commit b2fbf5a2), however this
might break the cases in which $XDG_CURRENT_DESKTOP is already set and
contains GNOME (given that is now a list).
In Ubuntu this is in fact set to: ubuntu:GNOME.
Now, if an application contains NotShowIn=ubuntu, the key will be ignored by
the shell, and the application is still listed everywhere.
So, override the DesktopAppInfo desktop environment only in the case that
the current desktop is not already GNOME.
At the current date I think we could just safely get rid of this override at
all, but there could be still cases where it still might be useful, like when
running as nested in some other environment, so keeping it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1156
In some situations we could end up not with lingering 'view-loaded'
handler. This could result in delayed spring animate-in being initiated,
e.g. after a minute after the activities overview was already closed.
Fix this by removing any lingering signal or later handlers when
unmapping.
Fixes: 5c33fe4a0ahttps://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1155
Promises make asynchronous operations easier to manage, in particular
when used through the async/await syntax that allows for asynchronous
code to closely resemble synchronous one.
gjs has included a Gio._promisify() helper for a while now, which
monkey-patches methods that follow GIO's async pattern to return a
Promise when called without a callback argument.
Use that to get rid of all those GAsyncReadyCallbacks!
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1126
Starting the animation from the actor 'paint' signal has various
unwanted consequences, such as sometimes trigger a
clutter_actor_queue_relayout() during the paint phase. One unwanted
consequence was that an offscreen actor effect was disabled during
painting, meaning the effect would begin being active, but later during
the post-paint processing being disabled. The caused said effect to push
an offscreen framebuffer to the paint context, but then just destroy it
instead of popping it. When this happened, we'd end up trying to operate
on a framebuffer that may had been finalized, or not, depending on the
garbage collector. Sometimes, for some users, this caused a segmentation
fault when trying to pop a matrix from the framebuffer matrix stack.
Deal with this more properly, by using the 'view-loaded' signal to wait
with animation until the view is loaded, as well as using MetaLater to
schedule the start of the animation.
For when a view was signalled to be ready, we're in a state where we can
start animation before the next frame as the layout is ready, but when
not, we have to add back the "hack" where we must wait for one frame for
the target icon positions to be up to date. Do this by adding a
MetaLater IDLE callback that starts the animation *after* the next
frame. This also needs the old 'opacity = 0' work around to not show an
incorrect first frame.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2418https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1154
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
Set the do not disturb label as the label actor for the do not disturb switch,
so that Orca speaks the do not disturb label when the user moves
keyboard focus to the do not disturb switch.
Also enable toggle mode for the "Do Not Disturb" button and bind it's checked
state to the state property of the switch. This makes sure that Orca presents
thecorrect state of the do not disturb switch to the user.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2508
It seems there is a weird race condition between Clutter trying to
destroy the keyboard actor and Clutter trying to hide the keyboardBox
container actor: If the keyboardBox is hidden before destroying the
keyboard actor, Clutter doesn't repaint anything and the keyboard
remains visible until something else draws over it.
To fix this issue until we find the underlying Clutter bug, simply
destroy the keyboard actor before hiding the keyboardBox. The order in
which we call these doesn't matter anyway since hideKeyboard(true) hides
the keyboard immediately without an animation.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1736https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
We're dealing with attached keyboards now using the touch_mode property
of ClutterSeat: If a device has a keyboard attached, the touch-mode is
FALSE and we won't automatically show the OSK on touches, also the
touch-mode gets set to FALSE when an external keyboard is being plugged
in, so that also hides the OSK automatically.
With that, we can now ignore keyboard devices when updating the last
used device and no longer have to special-case our own virtual devices.
Because there was no special-case for the virtual device we use on
Wayland now, this fixes a bug where the keyboard disappeared after
touching keys like Enter or Backspace.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2287https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1142
Since commit 2894085c45 we omit sound feedback on volume changes
if something is already outputting sound. Unfortunately that
"something" may be our own feedback (from a previous volume
change).
In that case we do not want to omit the new feedback, so instead
cancel the previous one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1147
Since commit 784c0b7e4 we use the name of the nearest city rather
than the weather station, as the latter tend to have unwieldy
and weird names.
However the nearest city may not be that near after all, in which
case the result is again surprising.
Address this by not using the nearest city name unconditionally, but
only if it appears in the station name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2468
AuthPrompt is created on demand, and this._authPrompt is
expected to be null except on very strictly controlled
occasions. The idle monitor callback isn't one of them.
Check if AuthPrompt exists before cancelling it.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2371
Instead of adding a dragMonitor for every icon in the grid as soon as
one icon is getting dragged, only add a dragMonitor for the icon that is
currently being dragged over (ie. the current drag-target). With a large
number of icons in the iconGrid, this should significantly reduce lags
while dragging.
We can do this by detecting the DnD-entering of an icon or folder using
the `handleDragOver()` callback of drag-targets, adding the dragMonitor
because we know an icon is hovering above the drag-target and then
detecting the DnD-leaving of the drag-target by using the `dragMotion()`
handler, where we remove the dragMonitor again as soon as the
targetActor is no longer our actor (ie. the drag-target).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While it should be impossible to destroy a FolderIcon while a DnD action
is still going on, there might still be rare cases where this happens
(ie. when a folder is removed because an app got deleted during DnD).
So make sure we're on the safe side here and don't potentially leave
dragMonitors around after the icon is destroyed by removing the
dragMonitor inside the onDestroy handler of the FolderIcon, just like we
do for AppIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/849
While we don't technically need the app to download and apply
updates, we do require it for notifying the user about available
updates and listing extensions with pending updates.
So instead of intransparently applying updates in the background
without the user noticing, disable updates altogether if the
Extensions app is not installed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2346
Blacklist support was added all the way back in commit 1e286e43, but
the code had been defunctional until recently. While uninstalling an
extension that has been blacklisted makes sense off-hand, unfortunately
we don't know if an extension was *actually* blacklisted:
The website returns that operation for any extensions for which it
doesn't find any versions that match the shell version. That is, the
most likely reason is that the user updated to a new GNOME release
which the extension doesn't support yet.
It doesn't look like the website is going to change that behavior any
time soon[0], so drop the 'blacklist' handling for the time being.
[0] https://gitlab.gnome.org/Infrastructure/extensions-web/-/issues/95https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1132
Commit 55b57421d changed signal handlers to the corresponding vfuncs,
but didn't always chain up as necessary. In most places this doesn't
matter, but at the very least the commit broke activating message list
items via the keyboard.
Add all (hopefully) the missing chain-ups to get the expected behavior
back.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2319
Destroying the policy invalidates it, so accessing it from a
Source::destroy handler (for example to disconnect signal
handlers) currently results in warnings like:
Object .Gjs_ui_messageTray_NotificationApplicationPolicy
(0x7f8c7c0a64a0), has been already deallocated — impossible
to access it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2238
Since PackageKit 1.11.1, the prompt to install updates on the end
session dialog has been (mostly) broken. The problem is that it only
works if PackageKit is running at the time the end session dialog is
opened; otherwise, our GDBusProxy has invalidated all of its properties,
which we read to see if update is possible. We need to autostart
PackageKit before reading its properties to fix this problem. That would
be easy if we were calling a method to see if an update or distro
upgrade were available, but since we're just checking a property, using
cached properties won't suffice. We'll have to manually check the
property value to ensure we autostart PackageKit.
Most of the code is written by Florian. Thanks Florian!
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2276
Previously we'd show the system background and then wait till the
main loop was idle before beginning the shell startup animation.
This resulted in one initial frame that was always just the system
background.
Now we try to get both the system background and the startup animation
begun on the same first frame.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1102
In telepathyClient we consider messages both Tpl.TextEvents and
Tpl.Messages, and we manually create JS objects to copy the properties we
care for each one. This may lead to objects not matching the interface we
want.
Instead, use an object with construct-only properties and two factory static
methods to initialize it.
Unfortunately we need to use the ChatMessageClass for the class name or
calling the static methods would trigger a gjs error as per [1].
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1113
[1] https://gitlab.gnome.org/GNOME/gjs/-/issues/310
We now warn on startup if screen locking isn't available, however for
users who choose not to use GDM or logind, repeating the warning on
each login is more annoying than helpful.
Instead, limit the warning to the first login on which the screen lock
became unavailable. That way the notification will still serve the
intended purpose of informing the user, but without being perceived
as nagging.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
As outlined earlier, in order to turn the Extensions app into a properly
sandboxed application, we need to split out the extension prefs dialog
and move it elsewhere.
With "elsewhere" being the new Extensions D-Bus service, effectively
turning it into a shell extensions portal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1106
On X11, _onFocusChanged() updates the input region, as well as the
reactive-ness of the dialog's buttons.
That method is not only used as signal handlers (which are correctly
disconnected when the dialog is hidden), it also runs when the "show"
transition completes.
That's a problem if the transition is still ongoing when the dialog is
hidden, as it will then only complete when it is replaced by the "hide"
transition, after the this._dialog has been reset to null, and trying
to access the dialog's buttons results in an error.
Avoid this by explicitly removing all transition on hide before
resetting the dialog.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2467
Commit c1ec7b2ff meant to fall back to the base layout in case
a variant like `fr+oss` is set up, but as we are checking for
'+' on the array rather than the layout name, the fallback only
"works" for a layout that is literally called '+', whoops.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2471
Detailed notifications are meant to be single line, just as unexpanded
notification banners. So handle them the same way as in the message
list, and replace embedded newlines by spaces.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2463
Some timezones, like the one of Kathmandu don't only have hour-based
timezone offsets, but their timezones are also offset by minutes. So
instead of showing weird values like "+5.8", show the minutes properly
in a format like "+5:45".
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2438
Extension updates are installed at startup, so any errors that bubble
up uncaught will prevent the startup to complete.
While the most likely error reason was addressed in the previous commit
(pending update for a no-longer exitent extension), it makes sense to
catch any kind of corrupt updates to not interfere with shell startup.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
When an extension is uninstalled, there is no point in keeping
a pending update: If the update didn't fail (which it currently
does), we would end up sneakily reinstalling the extension.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2343
Doing blocking IO in a graphical UI is bad, doing it in the compositor
is much much worse. So even if handling VPN requests is a relatively
rare event, doing it asynchronously is better.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
libnm doesn't only search for plugins in the regular VPN plugin directory,
but also in the legacy location and the directory pointed to by the
NM_VPN_PLUGIN_DIR environment variable (if set).
We don't monitor the additional directories, so it's possible for our cache
to become outdated.
Instead of trying to play catch-up with libnm's internals, do what nm-applet
does and use the appropriate API to look up the plugin on each request.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
checkForUpdates() will currently always query the server for updates,
even when passing an empty vardict of installed extensions. We know
there won't be any updates in that case, so avoid a pointless network
request.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1100
There are two ways for applications to provide a high contrast icon:
1. install an icon into the HighContrast theme
2. install a symbolic icon into the default hicolor theme
The latter is preferred nowadays, and implemented in the high-contrast
CSS variant by enforcing the symbolic icon style.
However together with the way we currently enable/disable high-contrast,
this can lead to the following race:
1. the GTK theme is changed from HighContrast
2. we reload the default stylesheet
3. the icon style changes to "regular", so we request a
new icon from the HighContrast icon theme
4. the icon theme is changed from HighContrast
5. we evict existing icons from the cache
6. we reload icons for the new icon theme; however as we
find a pending request (from 3), we re-use it
7. the request from 3 finishes, and we end up with a
wrong icon in the cache
The simplest fix is to change the icon theme before the GTK theme: Unlike the
theme name, the icon style is encoded in the cache key, so we won't re-use
an old (and incorrect) request in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2414
When launching the default calendar application, we special-case
evolution to make sure it starts up with the calendar component.
This is currently broken in two ways:
- evolution changed its .desktop file to use reverse DNS notation
- as evolution can now be distributed via flatpak, we can no longer
assume that 'evolution-calendar.desktop' exists when evolution does
(even though we ship the .desktop file ourselves, it is considered
invalid if the executable isn't found)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1093
At least for the time being, this looks like the easiest option to
launch the service:
- we could add a systemd unit, but then we'd need to update the
RequiredComponents in the fallback session definition as well,
making it necessary for gnome-shell, gnome-shell-extensions and
gnome-session to be updated to 3.36.1 in lockstep
- autostart is problematic as it would make gnome-shell conflict
with other notification daemons; also autostart is most useful
with automatic shutdown, which would require tracking signal
subscriber to determine when the service is unused
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
These paths are meant for Xwayland, not for X11 compositors being restarted
through alt-f2 + r. Maybe some signal analogous to init-xserver should be
added for Xwayland shutdown paths, but this signal we are currently
listening for is backend agnostic.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2329
Since the FolderViews are not connected to the "installed-changed"
signal, we need to reload their apps by calling _redisplay() when an app
is removed or installed. We can't connect to "installed-changed" inside
FolderView because we need to ensure _redisplay() of the FolderView is
called before AppView tries to access the apps of the folder inside
_refilterApps(). So reload the FolderViews inside AllViews _redisplay()
implementation to ensure everything is up to date before accessing the
apps of the folder.
Since the "apps-changed" signal of FolderIcon now indirectly triggers a
_redisplay() of the FolderViews, the 'changed' handler of FolderView is
now redundant and can be removed. Because of this, we also need to move
the emission of the "apps-changed" signal to the start of the signal
handler to make sure the view is updated before we try to access items
of the view.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1901https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
We should disconnect the folders "changed" signal from the folder in
case the FolderView or FolderIcon is destroyed. While at it, also remove
the unused this._spaceReadySignalId of FolderIcon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The _redisplay() function is usally used for subclasses of BaseAppView
which want to implement their own _redisplay() function, having that
function name in two classes which have nothing to do with BaseAppView
can be quite confusing. Make those names less confusing and call the
functions _sync() and _rebuildMenu() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
The viewBox has a border applied, so when we call adaptToSize using only
the content box of the container, the width of the border is not removed
from the content box and the grid will be allocated less space than what
we told it before using adaptToSize.
Fix that by adjusting the content box for the size of the viewBox, too.
This makes sure the correct amount of columns can be shown inside a
folder, since right now we only show 3 colums even though 4 would fit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1011
Since 38da479ee we correctly ceil the non-integer radius of the slider
handle when calculating the offset for drawing the circle. Since the
handle also has a border with a width of 1px by default, we should also
factor that in when calculating the offset.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Along the lines of `styleSheetName`, a session mode may want to provide its
own gresource file, so make this possible via a `themeResourceName` session
mode parameter, defaulted to gnome-shell-theme.gresource
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063
Unlike any other methods in the Extensions API, LaunchExtensionPrefs()
opens what appears to be an application dialog, except that it is
really a separate application that the caller has no control over.
In order to address that, add a new OpenExtensionPrefs() method that
takes additional parameters (modelled after the desktop portal APIs)
that will make it possible to improve the behavior in the future.
The new parameters are ignored for now, but pushing the API out now
will allow us to fill in the functionality post the .0 release.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
The 'disable-user-extensions' GSettings key is the last extensions-related
setting that isn't exposed over D-Bus, and therefore requires consumers
to access the GSettings directly.
Expose the setting as UserExtensionsEnabled readwrite property in the
org.gnome.Shell.Extensions interface to allow consumers to manage
extensions purely via D-Bus.
The 'disable-user-extensions' setting is the last extension-related
bit from the org.gnome.shell GSettings schema that is not exposed
via D-Bus.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074
Currently, a failure to start the Systemd unit `gsd-xsettings.target`
would be considered a failure to start Xwayland.
That means that if `gsd-xsettings.target` fails to start for whatever
reason, no X11 client can be used on Wayland.
However, XSettings is by no mean mandatory for X11 clients and many
legacy X11 clients do not implement XSettings. Those who do always have
a fallback path and therefore can still work without XSettings.
Make a failure to start the Systemd unit `gsd-xsettings.target` non
blocking for Xwayland, and just log a warning message.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1065
We ended up always showing the switch-user button on the lock screen,
as showing and hiding it with the prompt was too visually distracting.
But now that we have a fancy transition in place, we can easily extend
it to the switch-user button as well.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We only call _updateSensitivity() to make elements sensitive, and
nothing ever touches the sensitivity of the switch-user button; so
just call the corresponding authPrompt method directly, which is the
only bit that has an actual effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1029
We do spawn gsd-xsettings, and watch its name before notifying on the
given task, so the mutter bits can proceed with X11 startup.
One notable change is that we only start gsd-xsettings, instead of the
generic gnome-session-x11-services target. We do so as we have to wait
on a dbus name to appear in order to deem the initialization done, and
making it all depend on gsd-xsettings seems tidier.
Less notably, we also use ::shutdown-xserver to shutdown the related
services. Its major benefit is that it'd allow us to ensure the olderly
shutdown of those services, but it's unused at the moment.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/836
When a window is being resized by the compositor, with Wayland the
compositor first asks the window to change its size and emits the
"size-change" signal, and then emits the "size-changed" signal after
the window acknowledges the new size. To show a fancy resize animation,
gnome-shell creates a "screenshot" of the resizing window on the
"size-change" signal, and later animates that "screenshot" to the new
window size on the "size-changed" signal.
Now if a client is not responding to our requests asking it to change
its size, we get a "size-change" signal and start showing the
window-clone, but never a "size-changed" signal, animating and hiding
the clone again. This causes a so called "ghost window" that is shown
above everything else and never disappears again.
To fix that, start showing the window clone once we get the
"size-changed" signal instead of the "size-change" signal. This makes
sure the window actually updates its size and the clone is going to be
hidden again.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1078https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1055
Creating a new GTimeZone for the local timezone can be quite expensive if
done repeatedly. It requires an open(), mmap(), and parsing of
/etc/localtime.
This patch was provided by Florian, and I've tested it as far back as
3.28.4 to ensure that we are really reducing the number of open() calls
on the compositor thread.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1051
Signed-off-by: Christian Hergert <chergert@redhat.com>
The thumbnails actor `this._thumbnails` has already been destroyed when
calling `_destroyThumbnails()` from the `destroy` signal handler because
it is a child actor of the AppSwitcherPopup. So stop destroying the
thumbnails separately (fading them out inside a destroy handler wouldn't
make sense anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The correct property for the scroll-direction with scrolling events is
`direction`, no `scroll_direction`. This fixes scrolling in the alt-tab
popup, which broke with the actorization changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
When the switcherPopup was initiated successfully, we return true,
otherwise the WindowManager will try to destroy it. Since an early
release of the keystroke will also switch to another application and
close the switcher just fine, we should return true to indicate success
here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Right now the index that gets selected on click and motion events is set
when connecting the event inside the addItem function. If items are
added or removed (for example when an application is closed by pressing
"q"), this index isn't valid anymore and has to be updated.
To fix this, use the items themselves instead of the index as arguments
for the event handlers and lookup the index of the item inside the event
handler.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Set the accessible states of the switcherList items by calling a
function instead of manipulating class-internal variables from outside
the class, which is considered bad practice.
The check whether the item at `_selectedIndex` exists can also be
removed since we always select a new index after an item was removed
(i.e. an app was closed) and destroy the alt-tab switcher right away if
no more items exist (see `SwitcherPopup._itemRemovedHandler`).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Limit the minimum and maximum value to scroll to inside the box to 0 and
the upper limit, for some reason this was done right in _scrollToRight,
but not in _scrollToLeft.
This fixes the behavior of scrolling to the left: Before, scrolling one
item to the left moved the view to the first element of the list (this
can make the selected element invisible in large lists). Instead, scroll
one item to the left, just like scrolling to the right works.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Make sure the index that's being scrolled to doesn't change while the
scrolling animation is running by using an argument instead of the
this._highlighed class scope variable.
This fixes wrongly shown arrows when selecting new elements faster than
the scrolling animation takes for one index. The check run to disable
the arrow might be checking against a newer index than the one at the
start of the animation which results in the arrow not getting hidden
even if no more scrolling is possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
Since this._highlighted is always set to the currently highlighted
index, there's no need to save the index to a separate variable. This
obviously depends on getting the new item highlighted as a result of the
item-entered event.
This fixes bugs in situations where the highlighted element changes
after an event that is not calling _onItemEnter, for example after
scrolling or pressing a key. In those cases the _currentItemEntered
variable wouldn't be updated and the old item couldn't be entered
anymore without entering another one before.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/167
The 'gdm' user is not going to run a media player, so there is no
point in allowing the corresponding section on the login screen.
All other sections are already disabled, so this is the only reason why
we end up with the message list instead of only showing the calendar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2241
This reverts commit c0c027c608. Because for
some reason animating external opacity and position is still incurring
internal repaints, which disables offscreening and makes fading of
overlapping actors look wrong. `ON_IDLE` should be fixed in mutter before
it is used (in boxpointer at least) again.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2270
If the sessionMode does not allow to show the overview, we should also
hide an already visible overview.
This fixes a bug where, if the lockscreen was shown while the overview
was visible, the Ctrl+Alt+Tab popup would allow navigating inside the
overview because the overview actor is still mapped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1043
If a transition is reversed, the final property values will be the
same as before the transition. However this currently only works
correctly when we actually use a transition; to fix this with a
duration of 0, simply skip the set() call when the transition is
reversed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1042
While the unread messages indicator is updated when starting a new
session because we call _onSourceAdded() on existing sources, we should
also update the do-not-disturb setting which might still be enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1037
We turned both the auth prompt's cancel button and the switch user
button into icon buttons now, which means they are completely cryptic
when using a screen reader.
Just use the previously used labels as accessible names, which has the
nice side effect of lowering the impact of the string freeze break.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
Since commit mutter/a2a8f0cda we force the focus surface of the
meta-wayland-pointer to NULL while the pointer is hidden. This
introduced an issue with the magnifier, where we use
`set_pointer_visible` to hide the real cursor and show our own cursor at
the correct position: Because the meta-wayland-pointer is still used to
communicate with Wayland clients, the UI of the windows will not respond
to mouse movement anymore as soon as the real cursor is hidden.
To fix this, use the newly added clutter_seat_inhibit_unfocus() API to
temporarily disable unsetting the focus-surface while the magnifier is
hiding the system cursor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/993
If we are transitioning the label from 0 to its natural height, we
must set natural-height-set again after querying the preferred height,
otherwise Clutter would skip the transition.
However when transitioning in the opposite direction, setting the
property to true can go horribly wrong:
If the actor hasn't been allocated before, it will store a fixed
natural height of 0. But as there is no fixed min-height, we can
end up with min-height > natural-height, which is a fatal error.
(This isn't an issue when *actually* setting a fixed height, as
that will set both natural and minimum height)
So instead of always setting natural-height-set to true, restore
its previous value to fix the issue.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2255
Now that we apply a strong blur effect to the background, it doesn't
make too much sense to use a separate lock-screen background: It will
be mostly unrecognizable anyway.
The alternative would be to turn off the blur effect if a different
background is used (or have a hidden setting for that), but that would
then imply that we must keep the contents readable without blur.
Let's avoid that rabbit hole and just re-use the regular background.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1001
To bypass offscreening in cases where continuous animation is happening.
Offscreening is slower in such cases so this reduces the render time of
animations within offscreenable actors.
On an i7-7700 this reduces the render time of boxpointers for example by
25-30%.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1025
`-slider-handle-radius` is a floating point value and even in the default
theme it's not a whole number. Regardless of the fractional part that's
still going to occupy a whole extra pixel with antialiasing. So make room
for it. Otherwise it looks clipped, which it is by the Cairo context of
its `StDrawingArea`.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1569
Unused at the moment, but add the plumbing so that default key
definitions may specify symbolic icons that will be shown instead
of the text.
This is intended to replace the use of CSS and background-image
to handle those buttons with an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2214
For reasons not yet fully understood, `Main.uiGroup.add_actor` takes around
10 milliseconds to complete.
Because of this, each `actor.opacity = 0` has a good chance of falling
on a different frame. And when it does, `_opacityChangedId` also lands
on multiple different frames each incurring a separate relayout cycle.
It is this excessive number of relayouts that causes stuttering in the
icon grid animation (#2065). But it is the slowness of `uiGroup.add_actor`
that causes the number to be excessive when it should be one.
By creating the clones and adding them to `uiGroup` early, we then enable
the existing loop starting the animation to complete within a single frame.
And by completing within a single frame all the opacity changes land within
the same frame interval, thus incurring only a single relayout instead of
many.
This issue went unnoticed until 004a5e1042 (!704), after which the slow
emissions of `notify::opacity` became a more visible performance problem.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2065https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1002
Now that the bind constraint changes the preferred size of
the actor, a major flaw in the AppDisplay code was exposed:
the folder dialog depends on the preferred size of a parent,
and the parent depends on the preferred size of the folder
dialog.
While we know this is not actually true, we shouldn't rely
on broken behavior to achieve this result. What's interesting
is that the bind constraint used by the folder dialog is a
relic of the development phase; we now control the position
and size of the dialog with a combination of CSS, and alignment.
Remove the unnecessary bind constraint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1027
Since the design of the notification popup changed with the theme
refactor and there are now boxes around the world-clock and weather
sections, the overlay scrollbar that is shown above them looks rather
bad. So simply hide that scrollbar, we still have the vfade effect to
indicate the container is scrollable and we also depend on that in the
new popup app-folders.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1013
Make sure the stylesheet properties of the window-chrome title are
updated before requesting the preferred width of the title to prevent
size changes of the title after we animated the width.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/58
Remove the default icon size of -1 and always set the container StBin to
a real size. This fixes an error where the "width" and "height"
properties get set to -2 (which is -1 * scaleFactor) in the `_init`
function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1018
To make sure the GC really disposes the KeyboardController object we
need to remove all references to the object, which means we have to
disconnect signals the object connects to, too.
This also fixes a bug where keys remain pressed forever and thus also
break that key on real keyboards. It happens if the OSK gets destroyed
during an OSK-key is being held so the StButton of the key is not
released. That means the key remains pressed in the
MetaVirtualInputDevice that we are now leaking because
KeyboardController isn't garbage collected.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1015
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since quite a few strings of dialogs provided by external programs are
not updated yet and the string freeze is already in effect, make sure we
don't break those dialogs by stripping aways large parts of the
headline.
To do that, detect if the title label is larger than the available width
and if it is, switch to a smaller font-size of 13pt. This makes sure we
still show about the same number of characters in the headline as we did
in previous releases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1012
With the old screen shield, we were simply hiding the lightboxes to show
the shield when the user became active after activating the shield but
before locking the screen (that is, when using a lock-delay).
However now that the shield is gone, we end up showing the unlock dialog
even though we are not actually locked.
We probably don't want to add back a shield-like mode (that is, a way to
raise the unlock dialog without authentication when we aren't locked),
so just deactivate the whole shield when the user becomes active again
before the lock kicks in.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2213
The design team discussed the ellipses at the end of the hint text of
our entries and, even though they are present in most mockups, it turned
out they don't like them, so remove them.
It also turned out they don't like the prefixes like "Enter" before it,
so remove those, too.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
With the new dialog design the descriptions of entries are now
implemented as hint-text of the StEntry. That means the colon at the end
of the descriptions no longer makes sense and should be removed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/977
Currently separators get all the padding from regular menu items,
which is excessive for non-interactive elements.
Shuffle style classes around a bit to allow overriding the normal
padding for separators.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1004
Shift, caps-lock and friends change the capitalization of following
key presses. It is unexpected for those keys to have side-effects,
so don't switch to the prompt when they are pressed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2215
The promptBox is initially fully opaque, so showing it before the
transition can result in a brief flash before fading in.
Just remove the show() call and let the transition handle the
visibility.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2212
In the common case where we only have a single unread notification
from a particular app, the count doesn't add useful information.
Reduce clutter a bit by only showing the notification count if we
have at least two.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/997
Clicking or typing to reveal the auth prompt are good options for
mouse/keyboard workflows, but awkward on touch devices. Now that
we have SwipeTracker, adding corresponding gestures support is
easy, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
The current transition between clock and auth prompt uses a simple
crossfade.
"What kind of spatial model is that?!"
T.B.
Root the transition a bit more by adding translation and scale to
the animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
Currently, when a null user is passed, we don't add any
username label. That makes the layout of user and no-user
cases inconsistent.
Add a ghost label with no opacity to mimic the username
label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
If username-based login flow is followed, we need a default avatar
for the userWidget. Hence, check if the user passed to userWidget
is (null) which implies a username-based login flow.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the blur sigma decides how many pixels get factored in when
blurring and setting a scale factor increases the background texture by
that factor, the sigma value should also be multiplied by the scale
factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
There is nothing else to be focused in the lock screen itself -- the
top bar is already handled elsewhere, and the dialog manages itself
now.
Remove the lock screen group from the Ctrl-Alt-Tab manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
AuthPrompt is the set of actors that contain the user avatar,
the username, and the password entry. With the removal of the
screen shield, the unlock dialog (be it UnlockDialog or the
LoginDialog) is always created, and in the case of UnlockDialog,
so is the auth prompt.
This is problematic, though, since for passwordless accounts,
the simple act of creating AuthPrompt authenticates the user,
and lifts the lock screen.
Create the AuthPrompt on demand in UnlockDialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
As per the latest lock screen mockups, critical notifications must have
a more prominent, solid color.
Add a .critical style class to critical notification bubbles, and make
them darker.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Now that the screen shield is gone (at least, as it used to
be), the corresponding session mode is not necessary anymore
as well.
Remove the 'lock-screen' session mode, and the corresponding
CSS.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Pretty much what the commit title says.
This gives the lock shield actor another role: instead of
being the interactive screen shield, make it the invisible
actor that prevents interacting with windows while the
unlock dialog is sliding down.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The 'onPrimary' argument was being passed to dialog.open(). Turns out,
neither UnlockDialog nor LoginDialog use this parameter.
Remove the unnecessary 'onPrimary' parameter, and cleanup the related
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The use of the core idle monitor means that focus change events
are also delayed by keyboard interaction. Since the magnifier is
already in the business of pointer tracking, it's easy enough to
fire the pointer rest timeout from here, so focus changes are
accumulated and delayed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
We may get several a11y events setting the caret on the same
coordinates it previously was. Make focus tracking ignore those,
as we're jumping to the same coordinates again during eg. mouse
operation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the crosshair is clipped so it doesn't cover the pointer cursor,
the clip rectangle is skewed towards the bottom/right. This was
made so to accomodate the default pointer, but the unevenness stays
on other pointer cursors, and it makes the crosshair look odd on
short crosshair length.
Make all lines clip to an even distance from the center instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
It is somewhat unexpected that crosshair color and pointer cursor colors
remain the same across changes in color inversion settings, and may lead
to contrast issues. Apply the effect on the common container, so it
applies to these all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/984
If the icon proper has opacity of zero then that's probably because a
clone of it is animating. So avoid animating the source actor too.
And if there's any other reason for the opacity being zero, still don't
animate it because we can't see it :)
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2167
So as to guarantee the unmapped state sticks and doesn't get toggled
back to mapped before we return.
Being in a mapped state when `FolderIcon.vfunc_unmap()` returned was
causing an assertion failure in `clutter_actor_set_mapped` and crashed
the shell.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2170
Commit 147a743d8d moved the suspend and power-off actions into
the submenu that contains the log-out and switch-user actions,
but did not update the submenu visibility logic to account for
the additional actions.
As a result, the submenu is hidden when log-out and switch-user
are unavailable (like on the login screen), even if suspend and
power-off are enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2169
Now that we can download, apply and display extension updates, it is time
to actually check for updates. Schedule an update check right on startup,
then every 24 hours.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1968
If all password entries in dialogs are hidden, there is either an entry
that has visible characters or no entry at all. That means we don't have
to show the caps lock warning at all, so hide it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Since the headlines of the dialogs now use a much larger font, the
strings need to be shorter so they won't be ellipsized. So use a shorter
strings for those titles and also adjust the title-strings of the
notifications sent by the NetworkAgent to be consistent.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
