With the new boolean setting, the "High Contrast" toggle can now
simply toggle the setting instead of the current gtk/icon-theme
shenanigans.
This isn't only much simpler, but will also make switching between
high-contrast and a non-default theme reliable at last.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2069>
This is specifically for stopping the screenshot UI screencasts for now.
It's possible to stop arbitrary screen recording handles, however due to
an issue with pipewiresrc, this method cannot currently work for cleanly
stopping Shell's own screen recordings. Hence the best we can do is to
handle just the screenshot UI screencasts to let them stop cleanly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
There is now a location portal that provides a similar role
as our agent. Settings supports that portal in its application
panel, which allows users to revisit their choice later.
Unfortunately it uses a different permission store table, so
any permissions granted (or denied) through our agent won't
show up there.
To change that, switch to the same table as the portal/Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1945>
Before this, creating a separate instance of `Location.Indicator` failed
because it tries to create export the same DBus path.
This is useful for extensions adding panels on multiple monitors. But
it also seems like a cleaner design to separate the indicator widget
from the logically separate role as a Geoclue agent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1919>
We currently disable all network items on both the lock- and login
screen. While it makes sense to be very restrictive on the lock screen,
there are some (fringe) use cases for being more permissive on the
login screen (like remote home directories only accessible via VPN).
There's precedence with the power-off/restart actions to be less
restrictive on the login screen, and since we started respecting
the `network-control` polkit action, it's possible to restore the
old behavior if desired.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
NetworkManager installs a `network-control` polkit action that can
be used to disallow network configuration, except that we happily
ignore it. Add it to the conditions that turn a network section
insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
Setting up a connection for an Enterprise WPA(2) encrypted wireless
network requires Settings. That's not available when windows are
disabled via the session mode, so filter out affected entries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
The item launches the corresponding Settings panel when activated, which
doesn't work when windows are disabled by the session mode. Rather than
failing silently, turn the item insensitive.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1874>
The parameter to `ModalDialog.close(timestamp)` is optional. But when
invoked via the network dialog's Cancel button it was receiving an
implicit parameter value that's definitely not a timestamp:
```
[0x560f18af0c50 StButton.modal-dialog-linked-button:first-child hover ("Cancel")]
```
And as of today (or gjs >= 1.67.3) that's reported as an error:
```
JS ERROR: Error: Argument timestamp: value is out of range for uint32
popModal@resource:///org/gnome/shell/ui/main.js:638:12
popModal@resource:///org/gnome/shell/ui/modalDialog.js:206:14
close@resource:///org/gnome/shell/ui/modalDialog.js:179:14
```
and so you can't Cancel the dialog anymore.
Make sure `ModalDialog.close()` receives an `undefined` timestamp it
knows how to handle.
Fixes: https://bugs.launchpad.net/bugs/1918666
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1757>
This get's rid of the single-indicator introduced in one of the latest
commits. This was causing the accessibility pill in the top panel
to have different padding from the keyboard layout pill.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1615>
A side effect of removing the action buttons in favor of a regular
submenu is that we are a lot less constrained by size. So instead
of lumping "Restart" in with "Power Off", make it a separate menu
item.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2202
For more obscure network configurations, we need to launch the
corresponding Settings panel with additional parameters, so we
cannot simply launch the .desktop file.
However we can do better than spawning a command line: Control center
exposes an application action we can use instead, so the process is
launched with the appropriate activation environment and startup
notification support.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1385
This fixes an issue where the indicator can be out of sync until the
RfkillManager (used by it) properties change.
The problem is that multiple instances of the indicator will use
the same RfkillManager instance (getRfkillManager() returns a singleton)
that only guarantees to emit the changed signal in two scenarios:
when the D-Bus proxy connects and when the proxy properties change.
If by the time an indicator is instantiated the RfkillManager's D-Bus
proxy is already connected, that indicator would only sync its state
when the RfkillManager properties change.
Let's fix that by always syncing the state on construction - in the worst
case scenario the RfkillManager's D-Bus proxy won't have connected yet
and the indicator state will be temporarily out of sync but once it gets
connected the indicator will sync again with the correct state.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1386
Move the screencasting into a separate D-Bus service process, using
PipeWire instead of Clutter API. The service is implemented in
Javascript using the dbusService.js helper, and implements the same API
as was done by screencast.js and the corresponding C code.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
If a remote access is marked as a recording, visualize it the same way
as a built in recording. Also don't stop it if there is an actual screen
sharing going on, so that one can use a plain "recording" while still
disabling what is an actual screen sharing.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1372
The current microphone indicator only indicates if the microphone is in
use. Users might be also interested if their microphone is recording
or is muted, this commit enables that without opening the pop-up
menu. The microphone icon changes itself, depending on the sensitivity
of the microphone. It behaves similar to the already existing volume
indicator.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2902
Sliders can be operated by mouse scroll, but the mouse has to be over
the slider control. Make the brightness and volume system menu entries
forward scroll events to the sliders they contain so that scrolling
anywhere on the menu item operates the slider.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2795
While we now deal more gracefully with adapter removals, we can
still mess up the hadSetupDevices tracking:
As adapters become available before any devices, we'll always
reset the setting to false when Bluetooth is turned on. And if
no set up device happens to be in range, it will still be false
when Bluetooth is turned off again.
To address that, only update the setting if we have an adapter
(like we do now) and we had one before (so it wasn't the adapter
itself that changed).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Our intended behavior when bluetooth is turned off is to keep
the menu visible if devices had been set up previously.
However since gnome-bluetooth@c437c729, devices are removed
first before removing the default adapter, so we now end up
always setting the property to false before checking for it.
Fix this by deferring all model changes to an idle, so that
we can process them as a unit. Do the same for proxy property
changes, as those may trigger a row-removal.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
Since commit 26c2cb9f65, nDevices is always the actual number of
paired/trusted devices. So when bluetooth is turned off, it is
now 0 rather than forced to 1 if devices were set up previously.
Fix this by checking the property that tracks set up devices instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1174
