Prior to commit 7bd98f3f5f animation
onComplete handlers always occured at least after one main loop
iteration.
Now, if animations are disabled, they can get invoked immediately.
That breaks the endSessionDialog button handler, which calls
close before setting up the "closed" signal handler.
This commit fixes the handler to get set up first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2677>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2660>
There's a few things going on here, that unfortunately must
happen in lockstep:
- The gnome-desktop-3.0 dependency gets replaced by gnome-desktop-4
and gnome-bg-4. The code in ui/background.js required minor updates.
- The libnma dependency gets replaced by a libnma4 dependency. The
code in misc/modemManager.js required minor updates.
- The gtk3 dependency is torn down everywhere but tests. Some
missing GdkPixbuf dependencies had to be added to compensate for
its lack.
- gtk_init_check() is no longer called
As a result, we replace a hard gtk3 dependency with a soft gtk4
run-time linking one, only added indirectly through gnome-bg-4
and libnma4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
When the `QuickMenuToggle` was a discrete button, it could be set to
toggle mode, but the inner buttons no longer reacts as expected.
Bind the `toggle-mode` property between the `QuickMenuToggle` and its
contents so they behave as single toggle when enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2664>
Avoid the GTK dependency, and use the common GLib API to store
screenshots in recent files. While at it, give it a better
exec hint than the implicit "gnome-shell %u" GTK added for us,
nobody seems to pay attention to that, but if they ever did
it's better to provide sensible information.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2656>
gnome-bluetooth clears the list of devices when the adapter goes
away, but we cannot assume that that'll happen when powered down.
We don't want to show a (potentially outdated) list of devices
that cannot be interacted with in that case, so explicitly check
for the active state when returning devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2658>
The FolderView is a subclass of BaseAppView, which already has a
full-blown SwipeTracker attached to it. So no need to add another
PanGesture on top, the SwipeTracker will handle it for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2318>
NetworkManager frequently refreshes the list of available access points.
For some reason this often ends up removing some or all access points
only to add them back in a later refresh later. With the exception of
the currently connected access point, which is never removed.
When all access points of a WirelessNetwork have been removed, it gets
destroyed by NMWirelessDeviceItem::_removeAccessPoint(). This however
does not happen for the currently connected network due to the always
present access point. If this network now happens to consist of multiple
access points, the "unused" NMAccessPoints will get removed and added
in these refreshes, without the WirelessNetwork getting destroyed.
Whenever such an unused access point is added, due to the use of signal
tracking this leaks the NMAccessPoint and SignalTracker until the
WirelessNetwork is destroyed.
However when the NMWirelessDeviceItem is destroyed, for example due to
suspending, it stops tracking access point changes, ensuring that the
condition for the WirelessNetwork being destroyed can not occur anymore.
Even with just two access points, such as can be found in 2.4GHz+5GHz
home routers this issue leaks hundreds of NMAccessPoints and
SignalTrackers per day. As well as a small number of WirelessNetworks
which are also kept alive by the SignalTrackers.
To fix this disconnect from the access point when it gets removed and
destroy all remaining networks when the NMWirelessDeviceItem is
destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2652>
After an extension is installed, run `glib-compile-schemas` on its
`schemas` directory, if it exists.
This should avoid any endianess-related issues for extensions when
running GNOME Shell on varying architectures.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
This is something that will be used in other places outside the
background code, so let's just define it globally without having to care
about the importing order.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
We include a private hidden .desktop file for evolution's calendar
component, so that we can explicitly open that component when
evolution is configured as the default calendar application.
That's because the evolution developers didn't want to ship
additional .desktop files at the time, but they have since
then included a desktop action that can be used for the same
purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2479>
Switching between the app grid and the window picker in the overview via
gestures results in _gestureEnd() getting called with endProgress !== 0
in both cases, which leads to it calling _showDone(). This then
unconditionally changes the state to SHOWN, which in this situation is
already the current state. Since the previous commit this results in a
warning, so check if we are already in the SHOWN state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
There have been several bugs in the past that caused invalid transitions
of the `shown` state, such as going from `showing` to `showing`. These
cause consecutive emissions of the `showing` signal, which can confuse
other classes such as the search controller which connects to the stage
`key-press-event` on showing and disconnects again on `hiding`. Having
two consecutive `showing` signals will cause it to connect twice, and
only disconnect once when hiding the overview again. This will lead to
key presses getting repeated in the search until the session is
restarted. Because there is no obvious connection to how and when this
issue got triggered, this now adds some validation code that only allows
valid transitions and throws an error otherwise so we get a backtrace of
the code actually causing the problem.
This does not fix the issue(s) causing the invalid state transitions, it
only adds a way of tracking them down.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
Sandboxed apps that run without a window are detected by the new
background monitoring service, introduced by xdg-desktop-portal.
We have an opportunity to improve the predictability of the desktop
and ensure that application state in transparently reported to users
by showing these apps, and allowing them to closed.
Add a new background apps menu to the quick settings, that is always
added at the bottom of the popover, and has a slightly custom, flat
style applied to it.
Show background-running apps in this menu, and allow closing them
by first attempting to execute the 'quit' action through D-Bus, and
if that fails, sending SIGKILL to the process.
See https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/191
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2624>
Menu toggles are currently regular toggles with an additional
arrow button. This allows for a simpler implementation, but
has downsides with regards to keyboard navigation and hover
feedback.
To make it more obvious that the two parts of the menu toggle
perform different actions, change the overall structure of the
toggle to *contain* a regular toggle and the menu button.
That way each element uses its own hover effect, and shows up
in the keynav focus chain.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5964
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2632>
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>
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>
