Currently, handling of touch devices in the app grid is a bit awkward,
paging by dragging the view can only happen if started from the gaps
between icons, trying to drag from an icon will trigger DnD, and popping
up the menu takes over it all.
Instead, have the app grid actions play this game of rock-paper-scissors:
- Fast swipes on icons trigger scrolling, beats DnD and menu
- Slower press-and-drag on icons trigger DnD, beats scrolling and menu
- Long press triggers menu, beats scrolling, is beaten by DnD
This allows quick swipes to handle navigation, while still allowing the
fine grained operations. DnD, when triggered, dismisses the menu, if
shown.
This all could probably be nicer with a more stateful gesture framework,
we're not there yet though.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3849
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
This setting (by default, 0) sets a time threshold in order to allow
DnD. If the drag is shorter than this threshold, DnD will be cancelled,
and event handling left to the next handlers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
The switcherPopups use _next() and _previous() to get the items
in the text direction. I. e. with LTR _next() gets the right item;
on RTL it gets the left item. This doesn't work well with RTL when using
the arrow keys since the text direction doesn't matter in those cases.
Pressing Left Arrow should still move left regardless of text direction.
So use the opposite methods.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1835>
If for some reason the xserver failed to start, mutter/gnome-shell
should not attempt to connect to the X11 display otherwise it will
lock up in XCB.
An indication of such a premature failure of the xserver is when the X11
services fail to start.
Return the status so that the caller can cancel the connection in time
and avoid the lockup of mutter/gnome-shell in case of failure.
This, however, makes the X11 services a critical component to start
Xwayland, meaning that a failure to start those services for any other
reason than the xserver failing to start would still prevent Xwayland
and therefore X11 clients to run in Wayland. This is however a lesser
issue than mutter/gnome-shell locking up.
This basically reverts commit a96753f0 - "windowManager: X11 can work
without gsd-xsettings".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1837>
Change behavior on pressing Super+Number in Activities/Overview mode
so that the overview mode is hidden and application can be used.
This makes it consistent with clicking icon in the dash.
Closes: #4212
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1839>
Previously the workarea was only set on construction and then never
updated. As a result the preferred width and height as well as the
allocation were based on an outdated workarea size when it changed after
construction. This for example was happening during the startup
animation, for which the WorkspaceLayout is constructed before the panel
is shown. This caused the workspace in the overview to be slightly
smaller when it is first shown and the overview closing animation to
not expand the workspace to the correct size the first time it is
closed.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3945
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3816
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1771>
In the nested session the startup animation sometimes fails, weirdly
that always happens to me when running a freshly built gnome-shell the
first time. The reason it fails is that mutter fails to aquire a pointer
grab from the xserver, XIGrabDevice() is unsuccessful.
A simple workaround for this race condition in the xserver is to just
grab the devices a bit later, that is after the startups animation
instead of before it.
This was also tested with disabled animations, and seems to work just as
well in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1812>
Some drag actor parents might change their width to 0 after the drag
actor has been removed. If the drag is now canceled and the drag actor
is animated to return to the current parent position and scale, this
scale can not be determined and falls back to 1.0. This might be wrong
and can result in the drag actor being too large/small at the end of the
return animation.
To avoid this calculate the scale of the parent by recursively
calculating the product of its parents individual scales.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4017
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1790>
We want to clip the Workspace actor in the appGrid state of the overview
in order to make sure windows that overflow the monitor don't spill out.
So far we had commit b1970b95b8 for that.
Now since the last commit, window previews always slightly overflow the
allocation with their icons. That means a part of the window icon gets
clipped away as soon as the transition to the appGrid starts, which
looks weird.
Fix that bug in the transition by slightly extending the clip downwards
when animating between the window picker and the app grid state. The
extra height we extend the clip by is controlled by the overviewState,
which means we extend the clip by the full icon overlap in the window
picker state, but don't extend the clip at all when in the app grid
state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
We want to use as much space as possible for showing window previews in
the overview, and the title and close buttons of those windows are only
visible on hover, so we can show them above anything if we want.
On both primary monitors and secondary monitors, there's a certain free
space available towards the bottom edge of the monitor (on the primary
monitor we show the dash there, and secondary monitors just scale down
the Workspaces). We can make use of this by checking how much free space
there is available from the bottom edge of our allocation to the bottom
edge of the monitor, and then aligning the window previews to make full
use of this space.
So stop adding any padding to the edges of the Workspace, which will
make the windows a lot larger and completely fill the Workspaces
allocation.
The left, top and right monitor edges should always be far enough away
to accomodate the close button and hover scale-up of the window. Only
with the bottom edge of the monitor we have to be a bit more careful
(the overflowing height of the window title is quite big), so there we
check if enough free space is available. If there isn't enough free
space, we simply apply a bit of bottom padding again and shift the
window up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
Make the SecondaryMonitorDisplay a bit more similar to the
ControlsManager container on the primary monitor, and clip that widget
instead of the WorkspacesViews on secondary monitors.
This will allow us to overpaint the WorkspacesView allocation and paint
the WindowPreview overlays like the title and close button outside the
allocation with the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1813>
The original parent of a dragged actor might have been destroyed after
the drag has been started. When the drag is canceled and _dragOrigParent
is set, the code is trying to get the current position and size of it
when restoring. With a destroyed parent this however would result in a
crash.
This could happen for example when starting a drag on a window preview
while the overview is hiding and then releasing it once the transition
is done.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4024
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1817>
`ThumbnailsBox` listens for the `showing` signal from the `Overview` to
create its thumbnails and destroys them on the `hide` signal. Since the
`showing` signal can be emitted multiple times when switching between
the shown and hidden state without ever fully completing the transition,
this will cause `_createThumbnails` to be called multiple times, each
time adding another set of workspaces.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
When starting a gesture to open the overview while a transition to hide
the overview is running, Overview._shown will be first set to false when
starting the transition and then to true by the gesture before the
`onComplete` callback is called. The `onComplete` callback in this case
is `Overview._hideDone()` which starts a transition to show the overview
again which also emits the `showing` signal. Since the gesture emits a
`showing` signal as well, this results in two consecutive `showing`
signals without a `hiding` signal in between.
This breaks the `searchControler` which adds a key press handler to
start the search on `showing` and removes it on `hiding`. So every time
this happens a new handler that will never be removed is added,
resulting in the first key press being repeated.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4004
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3819
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1828>
When we press a key with variants, we used to prevent an
early ::pressed, because a long press could show the options
popover, and the press be undone.
In addition, this long press could move to one of the suboptions,
and be released there. For this case we also want this late
emission of the ::pressed signal.
This makes the "tap, drag, release" pattern work on the
regular OSK keys, in addition to the emoji panel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
This is already allowed for pointer events, but touch events still expected
that the touch begin and end happen on the same Key actor. Change this
behavior for touch events, this is necessary for the tap-drag-release
pattern to select key variants to work on all input devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1789>
When super is pressed again during the overview transition, we shift
up to the app grid. That means that the feature currently doesn't
work when animations are disabled (like in a VM), because there is
no transition in that case.
Address this by adding a time-based fallback in that case, i.e.
shift up when a second super-press occurs within 250ms after the
first one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4121
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1811>
Using the callback directly as signal handler means that it will
receive the signal parameters (in this case: the StButton instance
that emits the signal).
This leaks an implementation detail that is harmless in the best
case, but can break dialogs when using bind() on the callback.
Avoid that trap by explicitly calling the callback without arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4139
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1819>
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>
