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>
