This behavior makes more sense to have in the iconGrid itself: When a
page is filled up with items, the new item should never go to the start
of the next page, but always to next empty slot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Folders reflow across pages because they don't set
allow_incomplete_pages to true. This means we want the nudging of items
to happen slightly differently when dragging an item across pages:
- When dragging from lower page index to a higher one, always reflow
towards the start of the grid (because there's now an empty slot on the
old page and items on the new page will force-reflow towards that)
- When dragging from a higher page index to a lower one, we can reflow to
the end as we usually do
To archive this, factor out the selection of "reflow direction" into a
separate variable that always defaults to "end" (because empty space is
always at the end of the grid). Set it to "start" when the item created an
empty slot on the current page or (and this is new:) on a previous page in
the folder case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
The iconGrid's getDropTarget() API supports dropping items to adjacent
pages just fine, but in the AppDisplay, we clip the grid and don't show
those adjacent pages. That doesn't stop getDropTarget() from picking
drop targets which are on adjacent pages though, so we need to filter
those out in the layer above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Returning a page and a position for the drop target seems more
straightforward than returning an actual grid item in getDropTarget().
With the next commit, this will allow us to throw away drop targets that
are not on the current page.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
_getLinearPosition() is a function that converts a page and position
index to the "accumulated" index that includes all pages before the
page. The function is used by _addItem() and _moveItem() for getting the
new index of an item inside the _orderedItems array.
Now when passing -1 as position to _addItem() or _moveItem(), this means
the item should be appended to the page. Right now _getLinearPosition()
returns the last item index on the page when passed -1, inserting the
item into _orderedItems at this index will actually not append it, but
insert it between the second last and last item.
To fix it, let's make the whole thing more robust by explicitly passing
an item to _getLinearPosition(). This means we simply no longer have to
assume what "-1" means. Moving the call to _getLinearPosition() to
happen after addItem() and moveItem() ensures that the new item position
is used and not the old one.
This fixes issues where the _orderedItems array gets out of order when
moving or adding items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the click action when a grab operation
begins. With grab ops being based on ClutterGrab now, the action
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This reverts commit 2b3ab3ecec.
Since the window menu no longer uses a MetaDisplay grab, but directly
a ClutterGrab, this is ineffective. But also, grabs are stackable, so
it's fine to push the window operation grab first and then dismiss the
window menu grab, even when MetaDisplay grabs get ported to using
ClutterGrab underneath. We now can just grab right away, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
Device additions/removals are tracked by GvcMixerControl, which
doesn't change when unsetting the stream. So clearing the menu
manually was a workaround, not a fix.
It's also worth noting that I failed to reproduce the original
issue again, so it's possible that we were working around a
pipewire bug that has since been fixed.
This reverts commit 1b62b7ea0a.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616>
Since commit 7bd98f3f5f animateOutAndDestroy() destroys
the placeholder right away when animations are disabled. Connect to the destroy signal
before calling the function.
This fixes the following error:
Gjs-CRITICAL **: 16:51:35.195: Object .Gjs_ui_dash_DragPlaceholderItem (0x55b9a946da20),
has been already disposed — impossible to connect to any signal on it. This might be
caused by the object having been destroyed from C code using something such as destroy(),
dispose(), or remove() vfuncs.
== Stack trace for context 0x55b9a70d08f0 ==
#0 7ffe161bd070 b resource:///org/gnome/shell/ui/dash.js:835 (df3d61d32e0 @ 98)
#1 7ffe161bd170 b resource:///org/gnome/shell/ui/dash.js:901 (df3d61d33d0 @ 779)
#2 7ffe161bd290 b resource:///org/gnome/shell/ui/dnd.js:562 (3d4da0cfd420 @ 909)
#3 7ffe161bd360 b self-hosted:1115 (3d4da0c7ef10 @ 407)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2604>
Dropping a icon from the dash to the application grid will set this._placeholder
to null. However the AppIcon is still used to represent the application in the
application grid. If we click on it we emit a pressed event. Stop assuming
that this._placeholder is still valid in the callback, use the icon parameter
instead.
This fixes the following error:
```
Gjs-CRITICAL **: 18:22:39.003: JS ERROR: TypeError: this._placeholder is null
_ensurePlaceholder/<@resource:///org/gnome/shell/ui/appDisplay.js:1477:17
vfunc_button_press_event@resource:///org/gnome/shell/ui/appDisplay.js:3121:27
```
Fixes: 6fc93b78bc
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6317
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2606>
The videos directory doesn't necessarily have to exist, users are free to
delete it. Right now we don't handle this case and screencasting fails.
Let's handle it and fall back to the users home directory instead when
xdg-videos doesn't exist.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2594>
- increase the font size of clock elements
- increase the size of user avatars
- combines lock and login scss into one file
- clean up the css for avatars
- adjust the blur parameters of the screen shield
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2564>
In addition to the "overshoot/bumping into monitor edge" behavior we already
have, we also want to switch pages when simply hovering above the prev/next
page indicators.
This page switch shouldn't happen immediately though, it needs to be kicked
off using a timeout instead. The reason for that is that the next/prev page
indicators are large areas, and simply dragging there isn't enough of a
gesture to really interpret as "the user wants to switch pages".
After this page switch has been toggled once, it can be repeated using the
same "repeat" timeout we introduced with the last commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
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>
If we are getting purpose hint changes while the language switcher is popped
up, this likely means the purpose hint was actually triggered by the key
focus change induced by the language switcher popping up.
In this case, we on one hand would like to preserve the state that applied
before thise focus change, and on the other we very much want to avoid the
keymap change that would forget about the keys being pressed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6066
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2534>
