The API surface of IconGrid was originally meant to be only
setGridModes(), however findBestModeForSize() ended up being
called by AppDisplay code. Now that FolderGrid sets the modes
correctly, we don't need to skip calling findBestModeForSize()
anymore.
Always call findBestModeForSize() during IconGrid's allocation.
Add an underscore to findBestModeForSize() since it's now back
to be a private method of IconGrid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Back in the day, adaptToSize() contained mad maths to figure out
icon sizes. Over time, its scope was reduced, to the point where
we are today where it mostly just redoes some quick maths to
predict the grid size based on the CSS box model.
Remove adaptToSize() from BaseAppView and child classes. It still
is an internal detail of the IconGrid class, but it's not exposed
as a "public" method anymore.
This removal is not perfect, as it doesn't move or compensate for
any of page indicators and arrows code. This will be done in follow
up commits introducing a new layout manager for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
When selecting the largest possible icon size for restricted vertical or
horizontal space the options for low resolution icons were rather coarse
grained. This could often result in seemingly too small icons being
chosen in the app grid on systems with low vertical resolution, because
the next larger size would exceed the limit by a few pixels.
This adds two more commonly used sizes for application icons to have
some more options with restricted space.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2173
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2289>
Start using the new methods to simplify signal cleanup. For now,
focus on replacing existing cleanups; in most cases this means
signals connected in the constructor and disconnected on destroy,
but also other cases with a similarly defined lifetime (say: from
show to hide).
This doesn't change signal connections that only exist for a short
time (say: once), handlers that are connected on-demand (say: the
first time a particular method is called), or connections that
aren't tracked (read: disconnected) at all.
We will eventually replace the latter with connectObject() as
well - especially from actor subclasses - but the changeset is
already big enough as-is :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
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>
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>
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>
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>
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>
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>
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
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 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
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
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
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
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
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
Animating the icon spring using the `translation-x/y` properties instead
of the `x/y` properties avoids relayouts. There are still other non-icon
actors moving, but it's a big improvement.
Before: 595 relayouts per spring
After: 94 relayouts per spring
Reducing relayouts reduces reallocation, which reduces CPU-intensive
JavaScript execution.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/926
