On error, we currently print a warning and bail out early. That
means we don't hide the slider, despite it being non-functional
without the proxy.
Fix this by making sure _sync() is called in any case. While at
it, use an appropriate log level for the warning message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Properties are null while a proxy has no owner. Javascript helpfully
coerces that into `Number(null)` (a.k.a. 0), so we end up with a
broken slider.
Explicitly check that the value is an integer before doing the
comparison to catch that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
The new class abstracts away the nitty-gritty of bluetooth- and
airplane-mode handling, and exposes just what the UI needs.
This will become more important with quick settings, where there's
a stronger separation between top bar icon and quick toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn allows us to rely on the signal parameters to only process
changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Don't try to initialize and then enable an extension if it is not supported
in the current mode. Otherwise the extension will not be initialized, and the
initial ERROR state is not cleared. Once it is in ERROR state we can't enable
it anymore when we switch mode. Instead, leave the extension in INITIALIZED
state, so that it will be initialized when appropriate. This happens for
extensions that support the unlock-dialog mode but not the user mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2378>
`ShouldShowAirplaneMode` only considers whether airplane mode
should be shown for the form factor, not whether there are
any actual kill switches available.
That's tracked in a separate property, `HasAirplaneMode`.
Take that into account for our `:show-airplane-mode` property,
so that it reflects when airplane mode should and *can* be shown.
Right now we only show airplane mode when it is enabled (and
therefore available), but this will change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that by constructing the proxy manually, and then
initialize it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
In case where there are multiple in- or output devices, pulseaudio
or pipewire can pick the "wrong" one by default.
Allow users to change devices without opening sound settings by
adding a submenu to the sliders when there is more than one device.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2380>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
GNOME Shell will only update extensions if the org.gnome.Extensions
app is present. This commit adds alternative support for
com.mattjakeman.ExtensionManager to the extension updating mechanism.
It enables updates to occur when extension-manager is the sole installed
tool on the system. When both applications are installed,
org.gnome.Extensions is preferred at all times.
Fixes#5564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2358>
The logging function cannot be asynchronous, so move the override
into main.js where ExtensionUtils can be imported at the top level.
Importing ExtensionUtils in environment.js at the top level is not
possible because it would import Main prematurely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
If we only raise screenshot UI to top, ibusCandidatePopup can still
cover screenshot UI because each time ibusCandidatePopup updates it's
visibility it will raise it to top and this also happens if we open
screenshot UI via keybinding. This commit fixes it by only raising it
above keyboardBox, because keyboardBox is above all entries in modal
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
ibusCandidatePopup actually works as a top chrome because it always
raises itself above top_window_group when updating visibility, so just
initing it as a top chrome instead of initing it below top_window_group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
The overviewGroup's size is currently determined by the coverPane
actor. That actor is only shown during transitions, so we rely on
ClutterFixedLayout including hidden children in its size request.
That odd behavior is about to change, so we need to make sure the
overview still requests the correct size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2351>
When a window with a modal dialog gets minimized and at the same time
the dialog is closed, the WindowDimmer undim animation starts and gets
cancelled when the minimize animation is done, because that unmaps the
window actor.
In this case we want ensure the dimming effect still goes into a
proper state instead of being stuck mid-animation, so listen to
onStopped instead of onComplete for syncing state of the window dimmer.
While at it, clean things up a little and move the check for the
attach-modal-dialogs pref inside the _syncEnabled() function.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5581
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2349>
Right now, we don't pay much attention to visibility hints from IBus
about the candidates list for the OSK suggestions bar. Since some
IMs rely on this visibility being honored, do that.
To fix this, the visibility hints for the lookup table are now
propagated to the keyboard, so the Suggestions actor hides its
internal candidate buttons. Since the Suggestions actor gets its
minimum height from CSS, this does not result in OSK size jumps.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5601
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2347>
There is no hint about the currently selected language, but this exists
in the mockups. Add a dot ornament on the language that is currently
selected at the time of showing the OSK languages popup.
Since this popup is created from scratch every time it is shown, and
the popup is torn down with the OSK during replacement. This also
works for further times the languages popup is shown.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5598
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2346>
When calculating the on screen coordinates of events from the window
relative coordinates, using the frame rect will include the decorations
added by the WM for SSD windows. This was causing the calculated
coordinates to be slightly off. Fix this by using the client rect for
SSD windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2319>
Absolute screen coordinates are impossible for Wayland clients to
provide, because the clients don't know where the window is positioned.
Some clients, such as the ones using GTK 3 were providing window
relative coordinates even when screen coordinates were requested,
while others, such as GTK 4 clients, were just returning an error for
caret events or also window-relative coordinates for focus events.
So for this to work on Wayland we have to request window-relative
coordinates and translate them to the current focus window.
To ensure the correct coordinates, we have to only consider events
coming from the current focus window. All other events are filtered out
now. As a side effect this also fixes the magnifier always jumping
to a terminal cursor whenever there was some output, even if the window
was not focused.
This also needs some special handling for events coming from the shell
itself, which should not be translated to the focus window either. As
another side effect this fixes another bug that was caused by these
events already including scaling and getting scaled again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5509
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2301>
