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