Right now we have a behavior in the appGrid where "bumping" the cursor
against the monitor edge during DND switches the page immediately, and
holding it there (at the monitor edge) switches pages again after a timeout.
With the next commit we'll introduce another way of switching pages during
DND, that is hovering over the next/prev page indicator to switch pages. To
allow those two methods to play well together, refactor the "overshoot" page
switching to make the timeout into a more generic "repeat" timeout. This
means we can now divide page switching can be roughly divided into two
different steps:
- Switch page immediately when bumping cursor against screen edge, also
works when repeatedly "bumping"
- Switch page automatically again after a second when keeping the cursor at
the screen edge without moving
We'll reuse the "repeat" timeout that's introduced here in the next commit,
where we'll introduce page switching by hovering the next/prev indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
With MR https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335,
the page navigation in the app grid was redone and prominent, always visible
navigation arrows were added. This larger change in the navigation of the
app grid also involved changes to the drag and drop behavior.
Before those changes (in GNOME 42), switching pages during DND in the app
grid worked like this: By "bumping" the cursor against the monitor/appGrid
edge, an immediate page switch would be triggered. Leaving the cursor in
that edge area would then trigger repeated page switches every second. By
repeating the "bump" gesture (moving cursor back into the grid, then
"bumping" against the edge again), it was possible to switch pages even
faster than every second.
When adding the always visible navigation arrows, we briefly tried out a
different way of page-switching during DND with commit 09b975fa: The "bump
against monitor edge" gesture (or "overshoot" behavior as it's called in the
code) was replaced with a hover timeout on the navigation arrows. The idea
behind that was to allow hovering the navigation arrow during DND to
eventually trigger a page switch, which also makes sense.
The replacement of the "overshoot" behavior made some people unhappy though,
so it was decided to bring back the old "overshoot" behavior with commit
4dcae8dd. Due to time pressure before the release that didn't go very well
and we ended up with a mixup of both approaches that doesn't feel too
polished.
So let's try to fix that by first going back to the working "overshoot"
implementation as it was in 42, then slightly refactoring that
implementation, to finally incorporate the new "page indicator hover"
behavior that https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335
originally intended to use.
This reverts commit 4dcae8ddd2.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
The nPages property can be 0, which is the case in a stripped down CI
image without a single app to be listed, which means we can't clamp to
`nPages - 1`, since that'll give us a negative index and the following
error:
(gnome-shell:266): Gjs-CRITICAL **: 16:48:56.633: JS ERROR: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1236:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1582:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:499:18
_init/pagesChangedId<@resource:///org/gnome/shell/ui/iconGrid.js:1137:24
_removePage@resource:///org/gnome/shell/ui/iconGrid.js:454:14
_removeItemData@resource:///org/gnome/shell/ui/iconGrid.js:495:18
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:854:14
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:1277:29
_moveItem@resource:///org/gnome/shell/ui/appDisplay.js:1194:20
_redisplay/<@resource:///org/gnome/shell/ui/appDisplay.js:1085:22
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1080:17
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1370:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:633:24
_initializeManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:95:14
async*_init@resource:///org/gnome/shell/misc/parentalControlsManager.js:63:14
ParentalControlsManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:55:4
getDefault@resource:///org/gnome/shell/misc/parentalControlsManager.js:42:22
start@resource:///org/gnome/shell/ui/main.js:184:29
@resource:///org/gnome/shell/ui/init.js:6:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
When the overview is hidden just after starting GNOME Shell the app
grid is not populated yet. Thus, this._grid.nPages is 0. When the
overview is about to be hidden, we call goToPage(0) on the AppGrid.
This results in pageNumber being clamped to -1 and leads to the
following exception:
```
JS ERROR: Exception in callback for signal: hidden: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1237:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1584:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:1328:52
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:89:42
_hideDone@resource:///org/gnome/shell/ui/overview.js:589:18
_animateNotVisible/<@resource:///org/gnome/shell/ui/overview.js:566:55
onStopped@resource:///org/gnome/shell/ui/overviewControls.js:753:21
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:150:22
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:316:60
```
Connect to the overview hidden signal only after initializing the
AppDisplay content, so that goToPage(0) is not called when there
is no page yet.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5837
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2536>
This is a region where, if hovered while dragging, immediately goes
to the previous or next page. This behavior was lost during the
transition to the new app grid layout manager.
Bring back the drag overshoot region.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This brings back the ability to drop an icon beyong the last page.
Because the acceptDrop() method does not have access to the target
drop actor, to avoid an extra pick or manually calculating it from
allocations, simply store it during DragMonitor.dragDrop(), and
use the target actor in acceptDrop().
This commit also removes the last usage of SidePages, so drop the
enum too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This simplified the _handleDragOvershoot() callback quite a lot.
Instead of transforming point positions and checking them against
grid coordinates, merely check if the drop target is one of the
page indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Make the next and previous page arrows be StButtons, with their
'icon-name' property matching the current StIcon icon name, and
use the 'clicked' signal to switch pages.
Remove the 'button-press' callback the scroll view, since the
buttons take over this functionality.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This was lost 2 commits ago, but now we reimplement this in a
different way. There is some jesting with allocations, since
we cannot use transformed positions while changing translation
of the icons. This new implementation works regardless of the
screen resolution.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This is a major departure to how page previews used to work. Add
a new layout manager that handles showing and hiding page previews
and navigation arrows. Move most of the code handling page previews
to this new layout manager.
The layout manager allocates at most 20% of the screen width for
the previews, and at least the width of the arrow.
The next and previous page peeking effect is temporarily lost with
this commit, but will be reintroduced in later commits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
AppDisplay will require an extra padding applied on top of CSS
page padding. This is specific to AppDisplay and FolderView.
Add a new AppGrid class which subclasses IconGrid and adds this
extra padding - here called 'indicators-padding'.
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>
Another step in dismantling AppDisplay before reintroducing some
of the elements there. Instead of adding a certain amount of
padding, capped at 200px, always give the grid all available size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
The stack widget once was a ShellStack and had a prominent role
in layouting AppDisplay, but after a series of reworks it's now
effectively unused, and can be safely removed.
Remove the '_stack' widget from AppDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
We'll have to dismantle parts of AppDisplay and BaseAppView in
order to introduce navigation arrows in a way that won't drive
people insane.
Start this dismantling by removing the fade effect. It looks odd
for now, since we still set padding to the app grid, but that
will change soon too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Our search provider API has to be asynchronous to support remote
providers. It doesn't have to be based on callbacks though, now
that async functions provide a nicer alternative.
That is particularly true after gjs's D-Bus wrapper started to
generate promise-based method variants.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
The swipeTracker wants the distance between two pages passed to it in
confirmSwipe(). In case of the app grid, the correct distance is not the
size of the scrollView (which has the width of the whole screen), but
instead the allocation size of the iconGrid (which is the actual size
of a page in the grid).
So pass the allocation size of the iconGrid to the swipeTracker, this
makes sure the pages move perfectly in sync with the pointer when
dragging using the mouse or touchscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2275>
Creating these default folders still doesn't work. After some
investigation I found that's because the template we use for
the path when creating the `child` `Gio.Settings` instance
results in a double slash - it comes out as e.g.
/org/gnome/desktop/app-folders//folders/Utilities/ . dconf does
not gracefully handle this as many other things that handle
paths do, it considers it a programmer error. It results in
error messages like:
dconf_changeset_set: assertion 'dconf_is_path (path, NULL)' failed
which is slightly confusing. Anyway, we fix it by removing a
slash from the template.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2242>
In testing on Fedora, gnome-shell crashes here:
JS ERROR: TypeError: DEFAULT_FOLDERS[folder] is undefined
This needs to be a "for of" loop, not a "for in" loop, because
`folders` is an array of the hash's keys, not the hash itself.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2238>
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>
The default folders used to be created by gnome-software, as that was
where folder management used to be implemented. Since then, folder
management via drag and drop was implemented in the shell, and the
gnome-software code was removed.
The only bit that still involves gnome-software are the default folders
that are created on first run. Given that everything else has moved to
the shell, it makes sense to take over that part as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4948
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2110>
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.
But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).
And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
While the menu is popped up, we artificially keep the icon highlighted
by ensuring it's hovered, and muting events on the app icon until the
menu is popped down.
This is somewhat convoluted and won't work with Clutter.grab(), where
it will be the menu itself that is the owner of input events while
shown, so cut some corners and explicitly tell the app icon to be
highlighted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
The value can not actually be null at that point, but it's too
hard to spot for tools like coverity:
- before setting view, we chain up to the parent's acceptDrop()
- that calls _canAccept(), which we override and check for the view
Still, and extra ? doesn't hurt, and hopefully will make the tooling
happy.
CID 351269
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1950>
At least the last stable release of gjs has an issue with async
handlers for custom (i.e. defined in JS) GObject signals.
The handler still works, but evoking it prints the following warning:
JS ERROR: Error: Could not guess unspecified GValue type
We can avoid the warning by using the addAction() convenience
method, which makes for a small nice cleanup anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4531
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1938>
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>
