Testing the greeter UI in nested has been broken for a long time
now, because the backend isn't ready yet when we try to push a
modal (via the screen shield).
As running nested is only relevant for development and testing,
working around the issue rather than fixing it properly seems
fine, so do just that and slightly delay startup when testing
the greeter UI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2573>
This is meant to let perf tests initialize themselves earlier than they
would otherwise run.
This allows them to setup the necessary dependencies, e.g. create
test monitors or similar actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
When we unmap, the child widgets have already been destroyed, so we
shouldn't try to. To detect this, delete the references we keep to them
on destroy, and null-check the hide call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
The cached work area, which is the work area of the primary monitor,
effectively depends on two properties - the (global) work area and the
primary monitor - and we are only tracking changes to one of them. Also
track monitor changes to also cover the second case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
Doing it ourselves in the shutdown handler in layout.js means we won't
risk reacting to monitor changes that happen after gnome-shell prepares
to shutdown and the signal handler would disconnect itself in case we
used `connectObject(..)`.
This will currently never happen, but in the future perf tests will be
able to create virtual monitors for testing purposes, and they might get
destroyed during the shutdown procedures, causing us to react to them
when we shouldn't.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
Thanks to NetworkManager's connection name disambiguation, it's
pretty common for single wired connections to be named "Wired". This
is fine and what we want almost all times, but in the specific case
of quick settings, we already have a "Wired" string set as title of
the quick settings toggle, so having that as subtitle is reduntant.
Hide the subtitle label (by returning null) when the subtitle of
a wired network matches the title.
Fixes ab10b95d2d
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6369
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2627>
If there is a single connection for a given NMToggle subclass,
use the connection name; otherwise, transform that into '%d
connected'. This is better than the current "Device (counter)"
template, e.g. "VPN (2)", which would give us a quick toggle
with:
VPN
VPN (2)
Change that to e.g.:
VPN
2 connected
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Following the previous commits where we left the quick toggle title
open for the new title scheme, set the titles for all network pills
to what currently is the "default" name.
That means, we pull the device name from Network Manager for devices,
through the disambiguate function, and hardcode 'VPN' for VPN
connections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Instead of map the currently active items - for whatever they are -
into the quick toggle title, bind it to the subtitle.
This leaves room for setting static titles for device-backed
networks, such as Wi-Fi, Wired, Bluetooth, etc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Add a subtitle label to QuickToggle, with a less prominent font.
Make the subtitle invisible when no text is present.
This new property will be used by next commits to implement quick
settings with a static title, and a changing subtitle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
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>
