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>
With the introduction of the transparent panel in the overview, we
started making the panel text/icon color slightly brighter in the
overview and on the lockscreen to ensure best contrast. Now
unfortunately, setting the text color incurred a relayout of the
underlying ClutterText actor (fixed with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750), and
setting the icon color causes the icon texture to get regenerated
(fixed with
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932).
Regenerating the icon texture will replace the icon actor, which also
causes a relayout.
This relayout of the panel has been measured to add at least 1
millisecond (the numbers fluctuated a lot) to about 5 ms it takes to
layout the first frame when showing the overview.
Since https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/932 is
unlikely to land this cycle, this commit proposes a different solution:
Simply don't use a different color for text in the overview. To avoid
issues with contrast in the overview, make the default color slightly
brighter and change it from #ccc to #ddd.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1733>
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>
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This reverts commit 87558efbf1.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.
Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3833
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1745>
