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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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
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
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
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
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
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
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
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
