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>
Extensions can export asynchronous enable() and disable()
functions. To guard against re-entrancy when enabling or
disabling an extension, this commit adds two new states:
ENABLING and DISABLING which are set immediately prior
to calling enable() and disable() respectively.
This commit updates the extensions CLI and Extensions app
with new strings for these states.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2364>
When we're running in e.g. CI, or in a virtual machine without hardware
acceleration, and we actually want to enable animations despite the
potential performance implications, change the AnimationsSettings to
only inhibit if we're a XVNC instance or not hardware accelerated if
--force-animations wasn't passed.
Still inhibit animations if there is a remote desktop session that
explicitly disables animations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2560>
If we want to run with the welcome screen showing, it should be done so
explicitly. Hide it if there is a perf test running for now, so that
what we test is what is expected to be tested.
We also don't want to show the root user warning, since we'll be running
as root in the CI containers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2560>
This test runs all of GNOME Shell using the headless backend inside a
mocked D-Bus environment. The basic test tests, well, basic things, like
the panel menu, the overview, showing the app grid view, as well as
going back to the session view.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Move back actors that were adopted from mutter (window_group,
top_window_group, the feedback group) from the uiGroup to the stage, and
then destroy the uiGroup. This will tear down more or less all of GNOME
Shells actors gracefully.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
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>
Running dispose on the setting causes issues when we're being destroyed,
as the signal handler in the GSettings binding will be cleared by the
GObject itself before it has the chance, resulting in warnings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
With meta_exit() we bypass the tear down procedures, making the test
case excercising much less code paths. Use meta_context_terminate()
instead, as that exits the main loop and goes through proper shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Since commit 7bd98f3f5f the onComplete callback
is called right away when animations are disabled. As side effect, now
this._coverPane gets shown/hidden in the wrong order. Start the animation after
setting this._coverPane initial state, so that the animation callback can set the
this._coverPane final state without it being overwritten later.
Move the animation also after emitting the showing and hiding signals. So that the
order showing -> shown and hiding -> hidden is still preserved when animations are
disabled.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6096
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2532>
We currently initialize regions in all code paths except for the
greeter. But while there are no windows on the login screen, the
work area can still be used for positioning, for example for
notifications.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2546>
We assign (disambiguated) device names every time a device is added
or removed, and store the name on the corresponding menu item.
However menu items are only created when the device should be shown,
not necessarily when it is added (unplugged ethernet cable, ongoing
initialization, ...).
Fix this by tracking device names separately from device items, and
set the name on newly created items.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6040
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2529>
If the OSK is destroyed while visible without being close()'d first,
the completion mode might remain turned on. Ensure it is turned off
on OSK destruction so that typing-booster has no chance to remain
turned on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
Even though the emoji panel may be destroyed with the OSK, the swipeTracker
that is set up to navigate between pages is left lingering, and handling
events for some gestures in the stage. This results in warnings like:
JS ERROR: TypeError: this._panel is null
set delta@resource:///org/gnome/shell/ui/keyboard.js:720:9
_onSwipeUpdate@resource:///org/gnome/shell/ui/keyboard.js:750:22
_updateGesture@resource:///org/gnome/shell/ui/swipeTracker.js:670:14
vfunc_gesture_progress@resource:///org/gnome/shell/ui/swipeTracker.js:288>
on touch interaction after the OSK was shown and dismissed. In order to fix
this, issue explicit destruction of the swipeTracker when the emoji pager
actor is destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
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>
The quick settings menu is child of an actor at 0,0 coordinates,
simply transformed to look in place. However the parent actor stays
at 0,0, and gets a width/height that is able to contain the child
menu (even though the transform will push it outside the parent
actor).
This makes the parent actor (not meant to handle pointer/touch
input) to cover parts of the shell. Since this actor is also where
the Clutter grab happens, the menu is not dismissed either.
Make this parent actor have a 0x0 size, so that it can still act
as the parent for the quick settings menu, but does not actually
cover any area. This makes clicks around the top left corner work
again while the quick settings menu is opened.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5887
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2535>
The screencast service shuts down when not in use, so it is almost
certainly not running when handling the screencast shortcut.
Instead of making sure the service is restarted, just cache the
property when initializing the proxy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2533>
Some gstreamer plugins require a connection to the display server,
so they block until the server is up and running. That's why we
moved the check into the D-Bus service, so that the blocking would
not lock up the compositor itself.
However the block can still delay the service initialization so
much that auto-shutdown hits immediately when returning from the
constructor. If that happens, the proxy on the shell side is no
longer backed by a remote object when the init callback runs, and
all properties therefore resolve as `null`.
As a result, gnome-shell thinks that screencasts aren't supported
and hides the screencast button.
Fix this by holding the service during the gstreamer checks, so
that the auto-shutdown timeout only starts after the service is
ready.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6051
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2533>
In commit ee09c5c853 we chose to pick
the minimum value in order to preserve 0 instead of replacing it with
1. While returning 0 unconditionally when animations are disabled
seems the more logic thing to do, we were unsure about possible side
effects. Do the change now. Since we are early in the development cycle
we should be able to deal with side effects (if any) on time for the
next release.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2528>
The IBusInputContext currently seems to be a bit sloppy wrt propagating
the current state to engines after those are changed, this results in
engines possibly ending with purpose/hint/etc that do not actually
correspond to the current state.
Ensure this state is cleared on unfocus of our IBusInputContext, so
that the next time the input method receives an input focus, the new
state makes it all the way to the currently active engine.
Fixes situations in the GDM/lock screen password entry that IBus
would miss the PASSWORD hint set on the StEntry, and let passwords
be fed to engines.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5966
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
Besides user interaction, there's two users of IBusManager.setEngine():
- The code that toggles all IBus engines off on entries with PASSWORD
purpose.
- The code that toggles completion support on OSK presence.
These are currently pretty oblivious to each other. Make this
interaction more resilient by making all external IBusManager changes
more cautious about directly changing the engine, and revoke properly
the completion mode if it needs be (e.g. changing to a non-XKB engine).
But another notable change is that ibus-typing-booster is now preferred
always, over PASSWORD purpose hints. This is done to avoid possible
doubled attempts to change the current engine (and ensuing IBusInputContext
confusion).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
GDBusProxy transparently handles the remote object appearing and
vanishing. It is therefore not an error if the service is not
running at the time the proxy is initialized, so we proceed and
try to read the list of profiles which is null in that case,
resulting in (harmless but annoying) warnings.
Avoid this by only reading the initial list of profiles if the
service has a name owner.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5992
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2518>
When propagating keys from the OSK, we usually feed these directly to
the IBusInputContext and let the IM handle the effects of this virtual
key event (which may also include feeding a key event back to us).
But these functions may also return a FALSE value if the key was "let
through" by the IM, which means the ball is in our yard again, and
we are responsible of letting this event get to its destination.
If that happens, just fall through, so the string is committed to
the client as an UTF-8 string, or propagated through keyboard events.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5930
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2508>
Consider the existing input sources MRU only valid if it contained
more than one element to pick from. Fixes the following situation
with initial-setup sessions:
- Initial setup Session starts, with several input sources already
configured ("us" between them)
- InputSourceManager initializes, only the default "us" keymap is
available
- MRU list is constructed, "us" is picked
- InputSourceManager catches up with session configuration, the
other extra sources are added
- MRU list is reconstructed, "us" is already the most recent
- Session ends up with "us" picked, regardless of its position in
the list, and no MRU existing prior to startup
If we consider the intermediate single-element MRU list invalid,
it is still possible to pick the best default source between all
the configured ones (the one that was put first in the list,
basically), after initialization is complete.
But also, it is unnecessary to have if there is a single source to
pick from. After the sources list has two elements or more, the
MRU list will become effective and preserved during changes to
the available sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2495>
There are cases where the animation time is set to 0 on purpose
in order to not animate. When animations are disabled via
/org/gnome/desktop/interface/enable-animations those animation
times are increased from 0 to 1. This makes the "Caps lock is on."
message appear unconditionally in the lockscreen for a brief moment.
Select the minimum between the two values. So that an animation time
0 is preserved instead of being replaced by 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2471>
In older versions of GNOME, when a menu was used for Bluetooth devices,
we tried to avoid showing the Bluetooth menu to folks who didn't use
Bluetooth.
This kept causing problems as the menu would disappear if no
devices were setup and the platform "airplane mode" removed the
Bluetooth device from the USB bus, making it impossible to detect
whether a Bluetooth device existed, compared to a user unplugging a
removable Bluetooth device.
Closes: #5749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2488>
When updating the MRU sources if there was no prior MRU, we want
to go with the unmodified list of sources in visibility order.
However iterating over object properties happens in an undetermined
order, so the initial MRU list ends up picking a value at random.
In order to prefer the sources list in the same order than they
appear in the menu if there was no prior MRU, order the keys
when accessing it and building the initial list of sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2487>
Use Meta.LaterType.BEFORE_REDRAW to queue setting the bind constraint
offset in an idle callback. This is needed since the signals that
trigger updating the offset may be emitted during allocation, at which
point queuing new relayouts isn't ideal, since it could result in
relayout cycles. In this case, we really do want to relayout as a side
effect of another actors allocation, so make this explicit.
This fixes a few warnings such as:
The actor '<unnamed>[<StBoxLayout>:0x3138d70]' is currently inside an
allocation cycle; calling clutter_actor_queue_relayout() is not recommended
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2476>
When a `PanelMenu.Button` is added to the `statusArea`, its menu is
added to the `PopupMenuManager` if it has one at the time. If a menu is
added later or a new one set, the new menu is never added.
Move the call to `PopupMenuManager.addMenu()` from `_addToPanelBox()`
to `_onMenuSet()`, which is called when the `PanelMenu.Button` is added
and whenever it emits the `menu-set` signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2470>
Pipewire 0.3.52 via commit a1f33a99 introduced a change that affects how
long pipewiresrc holds onto the pw_buffers it dequeued. Before that
change the pw_buffer was held until the end of the videoconvert element
at the beginning of the pipeline. After that change the pw_buffer was
held onto until the filesink at the end of the pipeline. This was
starving MetaScreenCastStreamSrc of pw_buffers to record new frames
into, resulting in the majority of frames being missed, especially in
situations in which the encoder was taking longer.
Pipewire 0.3.57 via commit 1ea1d525 will allow queuing the pw_buffer
early again via the `always-copy` option. This however is only a
workaround until a proper solution is found in either pipewire or
gstreamer that does not depend on copying the buffer contents and
instead queues the pw_buffer again after videoconvert as prior to
a1f33a99.
Since it is not clear yet when a proper solution will arrive, this makes
use of `always-copy` as a workaround for now and should be reverted once
it is no longer needed.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585
Related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2461
Related: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2436>
The object the SignalTracker belongs to is stored in a map managed by
the SignalManager which keeps a reference to that object. This map is
never destroyed nor is any entry ever removed. This leads to all objects
that ever had SignalTrackers used on them being kept alive even after
all references outside of the SignalTracker are long gone. This then
also extends to other objects which are leaked indirectly through
reference chains from these objects.
And if some of those objects are GObjects, this will prevent them from
being finalized, leaking further resources. A StWidget for example will
not release its shadow textures.
Fix this by destroying the SignalTracker and removing it from the
SignalManager once the last signal it was tracking has been untracked.
A WeakMap could have been used as well, but we need the Map to be
iterable in some of the following changes.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5807
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5796
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
After the next commit, when some classes, such as PopupMenuManager try
to disconnect via a destroy handler, the SignalTracker might have
already been destroyed, so trying to get it from the SignalManager will
cause it to create a new one, which will then try to connect to the
destroy signal of the already destroyed object.
This could for example be triggered by changing backgrounds.
Fix this by not doing anything in disconnectObject if there is no
SignalTracker for that object.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
This reverts commit 085102be74.
We need the SignalManager map top be iterable at shutdown for some of
the following changes. A WeakMap is not iterable. This revert changes it
back to a regular Map, which re-introduces the leaks caused by this.
Those will be fixed differently by the two followup commits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
Due to !2056 the monitor config is 2 instead of 4 on the desktop.
However, the constant `Meta.MonitorSwitchConfigType.UNKNOWN` is fixed to
4, and may cause the initial selection to be out of index thus fail to
display the switcher. This replaces the above constant to the actual
length of the switcher items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2451>
If a device has multiple connections set up, then at most one of
those can be active at a time, which is why they are presented
as radio items.
In contrast, VPN connections are not mutually exclusive, each can
be turned on or off independently. Setting :radio-mode on them
currently means that VPN connections can be activated, but never
disabled.
So instead of abusing the :radio-mode property to give VPN items
the UI we want, use regular items that reflect the desired behavior
and explicitly set up the UI the way we want.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2426>
The object the SignalTracker belongs to is stored in a map managed by
the SignalManager which keeps a reference to that object. This map is
never destroyed nor is any entry ever removed. This leads to all objects
that ever had SignalTrackers used on them being kept alive even after
all references outside of the SignalTracker are long gone. This then
also extends to other objects which are leaked indirectly through
reference chains from these objects.
And if some of those objects are GObjects, this will prevent them from
being finalized, leaking further resources. A StWidget for example will
not release its shadow textures.
Fix this by using a WeakMap in SignalManager.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5807
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5796
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2450>
We got a shiny new screenshot UI last cycle, but only relatively
obscure ways of launching it: Keyboard shortcut or overview search.
The new quick settings provides us with a natural place to expose
the functionality more prominently, and at the same time reduce
the emptiness of the top row, in particular on systems without a
battery and when locked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
We will expose the screenshot UI from quick settings, including
on the lock screen. It would be odd to restrict keyboard shortcuts
more than the more accessible UI, so relax the modes for the
screenshot-ui and screen-screenshot shortcuts.
We still disable all screenshot shortcuts on the login screen, as
users don't have an obvious way to retrieve the screenshot files.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
We currently don't take the session mode's `hasWindows` property
into account when deciding whether window screenshots should be
allowed. Right now that doesn't matter in practice, because all
the ways to bring up the screenshot UI are blocked in those modes
anyway. This is about to change though, so take the property into
account to prevent an information leak.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
It is currently not possible to bring up the screenshot UI while
locked, but that is about to change.
We still don't want screencasts in that case, because they are
much easier to abuse for filling up someone else's disk.
That restriction is enforced by inhibiting remote access in the
backend, so trying to create a screencast session will fail anyway.
Still, not offering an action that is unavailable is better than
having it fail silently, so do exactly that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
When we aren't showing the power toggle (read: on systems without
a battery), all items in the top are located on one side. Address
this by "moving" the spacer between "Settings" and "Screen Lock"
in that case to balance items a bit better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
The quick settings code was first developed in an extension, which
meant it made sense to maintain compatibility with GNOME 42 and not
use the new :icon-name convenience property.
There is no good for sticking with that for GNOME 43 as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
Since we put the actual slider into a bin to get a proper focus
indication, the slider isn't focused anymore and its accessible object
is therefore invisible to the screen reader.
Fix this by passing the slider's accessible object to the actor
that takes the focus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2431>
NetworkManager can check if a network interface has "internet access" by
invoking a HTTP request.
The URI used for connectivity checking in NetworkManager can be configured
manually in NetworkManager.conf:
[connectivity]
uri=http://portal-check.exmaple.com/nm-check.txt
Portal Helper provides an argument to pass the URI that should be opened.
If this argument is empty it uses http://nmcheck.gnome.org as a fallback.
Pass the URI configured in NetworkManager to Portal Helper instead of
an empty string.
Fixes#1313
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2228>
This prevents _sync() being called after actor destruction (since actor
destruction became more reliable in mutter@3d94c7cc2) and so eliminates
this shutdown error:
```
(gnome-shell:35197): Gjs-CRITICAL **: 16:31:02.769: Object .Gjs_ui_calendar_Placeholder (0x559ed6e547e0), has been already disposed — impossible to set any property 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 0x559ed6022310 ==
#0 559ed783c5a8 i resource:///org/gnome/shell/ui/calendar.js:1012 (31955be5fc90 @ 148)
#1 7ffef8f38230 b self-hosted:1178 (32af8f6b0c40 @ 454)
#2 559ed783c518 i resource:///org/gnome/shell/ui/popupMenu.js:806 (31955be18ce0 @ 52)
#3 559ed783c488 i resource:///org/gnome/shell/ui/popupMenu.js:954 (31955be190b0 @ 168)
#4 559ed783c3f8 i resource:///org/gnome/shell/ui/panelMenu.js:189 (31955be88150 @ 41)
#5 7ffef8f3de60 b self-hosted:1178 (32af8f6b0c40 @ 423)
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2429>
It is generally not possible to differentiate between systems
without bluetooth support, and systems where a bluetooth adapter
is powered down.
We work around that by tracking whether there are any set up devices,
and keep the bluetooth visible in that case, even when no adapter
is present.
However commit eeabdd150c moved updating the setting into the code
that handles adapter changes, which is exactly the place where we
carefully avoid changing the setting because it would be too
unreliable (devices may have already disappeared, or not yet
appeared).
Fix this by changing _setHadSetupDevices() to _syncHadSetupDevices()
and call that everywhere _sync() used to be called, *except* on
adapter changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5714
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2409>
We do set the full OSK as LTR since keymaps are defined in that
direction. Other actors inside the OSK might want differently so
move this piece of setup to init(), so child actors can set their
own without the OSK overwriting the value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This should be handled in the capture phase so containers setting
up the drag gesture have an opportunity to handle events from children.
This also follows what the 3fg swipe gesture does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Update the emoji panel so it can handle ratio changes dynamically,
and propagate the ratio from the Keyboard itself, so that the
emoji panel has a size that fits the OSK panel it was launched
from.
This is more important now with widely varying ratios, like
extended keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This keymap requires the corresponding input method for Hangul
input, and the hangul mode to be enabled. Look up for the right
state, and use a corresponding 'us' keymap for english input
otherwise, in order to follow hangul IM behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Like OSK key buttons, we must avoid the default grabbing behavior
of StButton here. Hook to button-press-event to commit the selected
words, so we get a chance to prevent focus changes on the current
key focus.
Likewise, connect to ::touch-event to handle touch input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This mode changes the current IBus engine to ibus-typing-booster
under the rug (i.e. no changes in keyboard status menu) for any
XKB engine selected.
In order to make it useful for the currently selected language,
the typing-booster dictionary is changed to the current XKB
layout language. And since the OSK has its own emoji panel,
typing-boosters own emoji completion is disabled.
These changes only apply as long as the OSK panel is shown,
reverting to the original engine and typing-booster configuration
after it is hidden. This in theory also caters for users that
do have ibus-typing-booster enabled as an input source.
The final effect is text prediction for the language that is
being typed, according to the OSK layout, given that
ibus-typing-booster and the relevant hunspell dictionaries are
used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This action will replace CLUTTER_KEY_Backspace emission for
the OSK backspace key. Following the available mockups, implement
different modes of operation:
- Single tap deletes a single character
- Long tap starts deleting characters one by one
- Longer tap switches to word-by-word deletion
This is made possible via the input method surrounding text,
inspecting the string to look the previous char/word position
backwards, and relies on IM focus providing enough context.
Since deleting text and getting surrounding text are both
async operations, we make one happen after the other, until
the button is released.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Keep it consistent with the rest of the actions. For long press
handling (i.e. shift turning to caps lock), this also means the
release action should be cancelled after any long press, to prevent
both from taking effect at the same time.
Prior to this commit, we used to switch level (and hide the button
being pressed) on button press, which made its long press handler
never get a paired release and end up triggering caps lock.
Performing the action on release ensures the shift key button does
not fall into this situation, making this issue moot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Have these defined in the JSON files themselves, instead of trying
to add them from JS while minding the differences in number of levels
and rows.
This means more redundant data in the JSON files, but simplifies
OSK layout creation significantly, and allows finer control over the
appearance without quirks.
As a result, importing data from CLDR is no longer as straightforward
as running an script. After initial import, manual editions will be
required to add missing keys, assign key widths, and so on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
These actions are defined in the JSON files themselves, allowing
us to migrate away from the sets of pre/post default keys, and fold
them into the JSON files for fuller control on layout and appearance.
As a first migration step, handle the relevant actions in the buttons
created from the JSON files, so we can port these.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Instead of having callers handle pressed+released, emit string
commits on a distinct signal that is emitted all at once during
release.
This also unifies the behavior of keys that have an extended keys
popup and not wrt press/release behavior and key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Add distinct properties for label/icon, and commit string/keyval
actions. This makes keys figure less things on their own, allows
disociating aspect and behavior (e.g. label '↲' and keyval 0x13),
and makes the fallbacks clearer (keyval and label resorting to
commit string).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
We want the list to keep updating, so periodically request scans
from NetworkManager. The code follows what Settings does in its
wifi panel, including the used interval.
There's a cute little spinner in the menu header now, to indicate
an ongoing scan.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Unlike the old menu that restricted almost everything on the lock
screen, we went into the completely opposite direction with quick
settings and kept everything that does not launch windows available.
Extend that line to the network items, but still respect the
`network-control` permission.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
When moving to quick settings, we will no longer have a single
parent we can hide instead.
This is only really needed for VPN - devices go away when networking
is disabled, connections (as in: configuration) do not - but it's
simpler to just handle this in the base class than adding a
_shouldBeVisible() method the VPN section can override.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
If any device is in hotspot mode, use the corresponding item as
primary. Disable the (future QuickMenuToggle) menu in that case,
and turn off the hotspot when activated rather than toggling the
global wireless switch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Wireless items represent a single adapter, but wireless connectivity
is controlled globally under NetworkManager.
So instead of delegating activation to items, bind the :checked
property to the global :wireless-enabled property and toggle it
on activate.
As any wireless devices will change their state to UNAVAILABLE
when wireless is disabled, don't remove corresponding items in
that case to keep the section visible.
We don't want to hide the button to turn Wi-Fi back on when toggled
off :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Whether the device is used as a hotspot is currently only
used internally for the name and icon-name properties.
But hotspots need special treatment in the toggle as well,
so turn the method into a GObject property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
As the sections are about to turn into quick toggles, they need
to be able to perform an action on click.
Add an activate() method for that purpose, which either disconnects
all active items, or connects the primary item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
DeviceItems are sections, and therefore not actually activatable.
However when we port to quick settings, those toggles will need
to do *something*.
For that reason, provide an activate() implementation that
1. deactivates the device if currently connected
2. delegates the action to the most-recently used item,
the first visible item or the auto-connect item (in that
order)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
The primary indicator is a bit tricker than the VPN one: The source
of the binding can change depending on the connection, and we still
want to show it when there is a network connection we don't know
about (either because we don't handle the device type, or the
device isn't managed by NetworkManager).
Bindings still make the whole thing a lot nicer though.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
This is the last property that will be needed by the future
betwork quick toggles.
It maps to the same item as :icon-name, except when more than one
item is active. In that case, we overrule the binding and return
a generic name and count (like "VPN (2)").
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Again no big surprise, a property that will soon correspond to the
quick toggle's icon.
It is more involved than the :checked property though, which is just
a simple boolean.
To keep it as simple as possible, we set up a binding group and use
that to bind the :icon-name property.
As state changes, we then update the group's source with the item
we deem to best represent the section as a whole at the given
moment.
That is (in that order):
- the first active item
- the most recently used item
- the top-most visible item
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Instead of subclassing PopupMenuSection, it is now a plain GObject
that has a `menu` JS property.
That brings it a tad bit closer to QuickMenuToggle, which is another
GObject with a `menu` property.
We are on the final stretch now. Over the next couple of commits,
we'll add some (fake) properties so we can hook everything up,
and then it's finally time for the big switch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
We treat wake up requests the same as user activity, as in general
the two behave the same: Turn on the screen and reset the idle watch
until the system becomes idle again.
The big exception is when the screen isn't locked yet. In that case
user activity should interrupt the automatic screen lock, but a
request to wake-up the screen (like showing a notification) should
not.
Address this by ignoring wake-up requests while the screen shield
isn't active, as we can expect the screen to still be turned on at
that point.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5719
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2413>
Now that console.debug() makes it easy to log message with DEBUG
priority, we can be a lot more generous with logging without
spamming logs (by default).
Those turned out useful in figuring out the issue in the next
commit, so let's keep them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2413>
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>
The API surface of IconGrid was originally meant to be only
setGridModes(), however findBestModeForSize() ended up being
called by AppDisplay code. Now that FolderGrid sets the modes
correctly, we don't need to skip calling findBestModeForSize()
anymore.
Always call findBestModeForSize() during IconGrid's allocation.
Add an underscore to findBestModeForSize() since it's now back
to be a private method of IconGrid.
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>
Space will be less of a concern when each sections becomes its own
menu, but it's still not infinite. To address this, enable MRU
tracking and limit the list to the eight most recently used items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Devices do not have an associated timestamp, but as we can now
track the MRU order of their connections, it makes sense to consider
the time of the most recent succesful connection the timestamp
of the device item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We always display items sorted by name, but there are cases where a
second order by recency is interesting. Add an option to ItemSorter
to keep such a list and allow accessing it with another generator
function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Connections have a timestamp property, which records the last time
it was succesfully activated. This is useful information to us, as
more recently used connections are likely more relevant than ones
that haven't been used for a long time (or not at all).
To make use of it in the future, expose that timestamp as a property.
Only connections support it, but we will soon provide a reasonable
value for devices as well, so add the property to the base class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Eventually each section will turn into its own menu, which should
include a single settings item.
This also removes the odd duplication of items, now that we avoid
using submenus where possible.
In general this is straight-forward, except for modems: Some
models are now supported by a dedicated wwan panel, while others
still use the generic network one.
Address this by adding items for either panel, but only show one
at a time. The new panel is used if *any* modem is supported,
only when all modems require it, the legacy panel is used.
Hopefully that shouldn't be an issue for many users, as using many
different modems with different capabilities should be fairly rare
(except for Aleksander Morgado, but I think he can handle it)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently stopped using submenus altogether, but that only works
- if there is a single connection that represents
the device as a whole
- if there is just one device, so it is unambiguous
what device items belong to
To implement that behavior, add a 'single-device-mode' property that
NMDeviceSection can set on its items, and have items update their
'use-submenu' property based on that.
For wireless devices it's a straight mapping, as its items represent
wireless networks that can appear and disappear by just walking around
(multiple wifi adapters also sounds rather fringey).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that device sections manage a list of items, and the VPN section
manages a list of items, it's time to split out a shared base.
The class will get more involved over time, and eventually become
the base of all network quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We got the indicator out of the business of tracking connections,
now it's time to do the same for devices.
Let sections track device additions and removals, and create device
items for them as it sees fit.
It also allows the sections to handle the ::activation-failed signal
by themselves, instead of passing it on from device items.
With this, the indicator is now solely responsible for global state:
Manage the top bar indicators, notify on connection failures, and run
the portal helper when NetworkManager detects a captive portal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
As mentioned when doing the same for VPN connections, it is currently
the indicator itself that keeps track of added and removed connections.
It then has to figure out the correct section, and iterate through all
its device items so each item can check whether the connection
corresponds to its device.
Stop that mess, and let each device item keep its connections updated
by itself. That is actually way easier, as NM.Device already exposes
available connections through a property, so we can get rid of all
the checkConnection() shenanigans.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently wait until we got a connection to NetworkManager.
That's possible because the old PanelMenu indicator API takes
a menu, so it is possible to add or remove items dynamically
later.
That won't be the case with quick settings, where `quickSettingsItems`
is a plain array that is only read once when adding the indicator.
Prepare for that by moving section initialization into the constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that wi-fi devices will be handled by a separate menu toggle
instead of as part of a combined system menu, there is no longer
a need of delegating network selection to a separate dialog.
To keep the menu from growing too much, the (sorted) list of
displayed networks is kept at a limit of eight. There is always
Settings for a complete list…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
In terms of UI, this means that in the common case where we have
a single (or no) connection, the device can be represented as a
single menu item rather than a submenu.
But more importantly, all our menu items inherit from the same
GObject class now, so we can use bindings where appropriate.
This will later extend to quick toggles as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class implements a menu item that contains a section which
can be collapsed into a submenu.
It is very common for network devices to only have one associated
connection, so hiding away a single item in a submenu is fairly
inconvenient.
This class will address this, by only using a submenu when it is
actually needed.
Although the main issue it addresses is that menus (including
sections) aren't GObjects. This gives us a GObject that can
be added to a menu, and that can itself contain other menu
items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class only provides the GObject properties that are currently
defined by NMConnectionItem, plus a way to set the active connection
that should be used for the item's :is-active state.
Its sole purpose is to provide a shared base for both device- and
connection items, and to have that base be a GObject so we can
start linking properties via bindings rather than manual fiddling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Let's keep things simple and use the same appearance regardless
of the number of configured VPNs. Also unlike for device items,
every connection item in the VPN section is a toplevel item, so
there isn't a real need for different presentations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The NMConnectionSection class is used - surprise - to manage a
list of related connections. And while the presentation of VPN
items is slightly different from connections associated with
devices (switches vs. ornaments), it makes perfect sense for
the VPN section to share the nitty-gritty with the base class.
But…
Right now it is perfectly fine for NMConnectionSection to be
used both as a child element in a device section, and as toplevel
item of the VPN section. Any nesting of sections is entirely
transparent to the user, and all connection sections appear as
submenu items in the toplevel menu.
That won't work for quick settings.
There's no PopoverMenuSection that allows invisible grouping, so
adding items dynamically would either need to happen at the end,
or require some tricky cross-component code to impose a particular
order.
And last but not least, quick toggles are very much unsuited for
a potentially large number of items. The whole point is to provide
quick direct access to system features, not to compete with menus
over the number of items they can hold.
That is, we need to get from the current state where each device
appears as a toplevel item, to a state where we have one quick
toggle for each device type plus one for VPN.
The decoupled VPN section still behaves largely as it did as a
subclass, with the notable difference that it no longer uses
a submenu item, so all VPN connections now appear at the toplevel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Right now the indicator itself tracks all devices and connections,
creates and destroys the corresponding menu items, matches them
to a section and updates the connection/device arrays that are
attached to the section.
Sounds messy?
It is slightly less effective to connect multiple handlers to the
same NMClient, but let's assume that devices and connections aren't
added/removed at 60 frames/s, and we can add some readabilty by
moving the code into different classes that only have to care about
the bits that are relevant to them.
The VPN section is a good starting point, because its handling is
already quite different from device sections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
At its core, it's the sort order tracking from NMConnectionItem
with a bit of sugar on top to provide access to the ordered items
and the ability to provide a custom sort function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
You could argue that the item name is closer to what is displayed
to the user, but it doesn't really matter: Connection items will
always use the connection ID when there is more than one, which
is the only case where sorting matters.
However sorting by items will allow us to generalize the code, and
use it for items that do not represent a connection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, when the connection is the only
connection for its device - we want the item to represent the
device as a whole.
Achieve this with a small ConnectionItem subclass that adds a
:device-name property for that purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, in the single-connection
case - the item currently uses a plain 'Connect' label.
That is OK while the item is inside a submenu that describes
the device, but we will soon stop using a submenu when a single
item can describe the device as a whole.
Prepare for that by adding an icon that is shown when in non-radio
mode, and include the device name in the label in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Newer versions of IBus (> 1.5.26) have the IBUS_CAP_OSK capability
which can be used to hint the active IM about an OSK driving input as
opposed to a physical keyboard. This may be used by IMs to tweak their
behavior to suit OSKs better.
Add the GNOME Shell side handling for this capability, and toggle it
on whenever the OSK is visible.
Since this is a far too new enum value and we don't want such new
IBus dependency, this change plays fast and loose with JS guarantees,
since a logical OR with an undefined value results in the other operand
unmodified it will work for older versions where the capability does not
exist and thus we want nothing extra enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2415>
We are calling _loginScreenSessionActivated() even in cases where this is
not required. For example, there are cases where the Active property is
already `true` and properties like `IdleHint`, `IdleSinceHint` and
`IdleSinceHintMonotonic` change. In this cases _loginScreenSessionActivated()
is called and will reset the authPrompt when not necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2411>
We do want to update the best AP on strength change, in case we
can switch to a better one.
But even if we can't and the AP is unchanged, the icon should
be updated to reflect the change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2414>
Right now DeviceCategory is a small section wrapper that shows
a summary instead of its content if it contains too many items.
It will eventually eventually turn into the base class for
network device quick toggles. Who would have thought that
when it was added for the "there's a computer with 32 ethernet
cards" fringe case?!
For now, give it a more appropriate name and use device types
instead of our made-up categories, now that the two map neatly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
It's odd to swap out a switch with a status label, and the
information isn't that helpful to begin with: It's either
transient (connecting, deactivating, ...), or too little to
be meaningful (unknown, failed, ...).
We're also perfectly happy to not show it in "label mode"
(i.e. when there's just one VPN).
Just get rid of it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Stop providing detailed state descriptions, instead use a name
that best represents the device at the moment (like a wifi SSID,
the carrier name, or the device name as determined by network manager).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The _devices property is another case of overloading the
"device" term.
Fun fact:
this._devices[device._delegate.category].devices
uses three different meanings of "device" (section, NM.Device, item).
The devices array in sections won't be around for much longer,
but the property that tracks the sections is worth renaming.
While at it, use a map instead of a plain object, which has a
guaranteed order when iterating (which will come in handy later).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Different access points can belong to the same wireless network. As
NetworkManager doesn't handle this for us, we need to track networks
ourselves, and we currently do this using ad-hoc object literals and
monkey-patching.
Clean this up by factoring out a proper WirelessNetwork class, and
associate them to items with a map.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Interpreting the different flags is better left to the domain
experts at NetworkManager. It is also much more likely that
NM's own functions will handle newly added flags than our own
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is a straight mapping between running/enabled and visibility,
so bind them instead of using a signal handler.
_syncConnectivity() is called both from _syncMainConnection() and
on connectivity changes, which should cover any running/enabled
changes.
That just leaves updating the icon on state changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We would want the signals to be disconnected if we ever happened to
destroy the indicator. Even if we don't, connectObject() is simply
nicer when connecting half a dozen handlers at once.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is only one case where we show a notification: When activating
a connection failed.
There is therefore no reason for a generic wrapper around the
notification API. Likewise, tracking the source is a bit pointless,
given that the notification is transient. In fact, as we destroy
an existing notification *before* checking for the source, any
previous source will be gone by that point.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The function is a handler for the `notify::state` handler, so
the state and reason parameters used in the checks are always
undefined.
In addition, `DEACTIVATED` is not (just) a failure state. We
clearly don't want to complain about a failed connection when
the change happened on request of the user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We never used it, so after more than ten years, it seems safe to
assume that we never will.
Plus different items pass different types, which makes it pretty
much impossible to use, even if we wanted to (which apparently
we don't 🤷️)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
When deciding on whether to show the 'no-route' icon, we check
for the client's connectivity *and* whether the devices's active
connection is used as primary connection.
This is currently masked by the indicator updating the icon on
connection changes anyway, but items should still notify the
change themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The wireless device item tracks the active access point in order
to update its icon on signal strength changes.
However we currently don't synchronize the initial state, so we
miss strength changes until the first access-point change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Otherwise any unrelated errors in that function are hidden,
because exceptions in async functions are turned into promise
rejections (and JS cannot know that we won't handle it at a later
point).
It wouldn't happen to me of course 😉
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
I wasn't genuiously going to touch those lines, but I ran into
a limitation of the run-eslint script:
It currently bases changed lines on a diff between HEAD and main
instead of the commit-by-commit log.
The two can vary quite a bit when shuffling code around, and those
are the lines the tool kept complaining about.
I'll look into improving the script, but for now it's quicker to
just shut it up by fixing up the complaints.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There isn't always a serviceName when we set a message. Furthermore we
are passing the serviceName only to decide if we want to wiggle or not.
Pass the wiggle parameters instead. If they are missing, we don't want
to wiggle.
This fixes the following error:
JS ERROR: Exception in callback for signal: login-format-changed: Error: Wrong type number; string expected
setMessage@resource:///org/gnome/shell/gdm/authPrompt.js:542:13
_showRealmLoginHint@resource:///org/gnome/shell/gdm/loginDialog.js:931:26
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47
_updateLoginFormat@resource:///org/gnome/shell/gdm/realmd.js:85:18
_reloadRealm@resource:///org/gnome/shell/gdm/realmd.js:57:14
_onRealmLoaded@resource:///org/gnome/shell/gdm/realmd.js:64:14
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:245:34
Fallout from 526f0711f1.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2404>
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
