vino does not work in Wayland sessions and gnome-settings-daemon
removed vino support in [1] which will effectively not start
'vino-server' any more.
The replacement for vino is gnome-remote-desktop since it works in both
Wayland and X11 sessions.
The gnome-remote-desktop sharing panel however is currently only shown
for Wayland sessions, which makes it harder to use it for X11 sessions
since the user has to login into the Wayland sessions just to be able
to enable gnome-remote-desktop.
Therefore, also remove vino from g-c-c and replace it with
gnome-remote-desktop for X11 sessions, too.
[1] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/135
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/212
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/937
Use 3 symbolic colours to paint the levels in the battery bars, with a
red "error" colour used for the lowest level of battery, an orange
"warning" colour for the pre-error level, and a green "success" colour
used for levels above that.
There's no yellow intermediate colour as this is usually too anxiety
inducing and there's no real need to press users into a "warning"
behaviour when the level will still be comfortable for a long enough
time.
Closes: #725
This matches the preferences available in a lot of other OSes, whether
desktop or mobile, and can help with identifying the state of the
battery quicker for some people, as a number might be parsed quicker
than an icon/colour combination.
Closes: #481
(gnome-control-center:172393): libupower-glib-WARNING **: 15:00:10.866: Property ID 'power-supply' (6) was never set
(gnome-control-center:172393): libupower-glib-WARNING **: 15:00:10.866: Property ID 'is-present' (8) was never set
(gnome-control-center:172393): libupower-glib-WARNING **: 15:00:10.866: Property ID 'battery-level' (28) was never set
(gnome-control-center:174498): libupower-glib-WARNING **: 15:04:44.859: Property ID 'time-to-full' (24) was never set
Add any wifi devices that have become managed or remove ones that have
become unmanaged. Since a device could have been added or removed
previously, we also have to handle multiple calls to add or remove a
device.
This appears to be largely vestigial code from a time when a GtkTreeView
was used here. It is very confusing, because someone reading the code
expects this to be critical to what's displayed on the screen, but it
isn't.
If I understand correctly, the only place this was still useful for
something was in `cc_keyboard_manager_remove_custom_shortcut()`, to check
that the CcKeyboardItem is valid. If I understand, this is a sanity
check that should never fail, so this seems unnecessary, and I've
removed it.
If that check is actually important, it would be better to have a
`GHashTable` of custom shortcuts, which should be simpler and clearer.
`sections_store` should similarly be removed/replaced. It seems to only
be needed in `add_shortcuts()`. But that seems like it can't just be
removed, so I haven't changed that yet.
When a retry event happens we need to wiggle the label, unfortunately we
can't just use translate operations via CSS so we need to simulate it using
padding.
Also we have to manually reset the retry class once the animation is done
otherwise gtk won't re-animate again once the class is added (in the same
paint cycle).
Implement the new designed interface for fingerprint enrollment, so that the
dialog is now based on a stack of views:
- A list of devices to choose (shown only if multiple are available)
- A gallery of enrolled prints available where manage them
- An enrollment progress view when enrolling a new finger
Move part of the logic into a new FingerprintManager (to manage gdbus proxies
generated via gdbus-codegen) that is created when configuring the current
user and that tracks the devices states, while move most of the UI into a new
CcFingerprintDialog that does all the operations in async way.
Due to fprintd lack of APIs, there are few features missing, compared to
the final design (none is a regression):
- Identify the finger when the enroll dialog is visible
- Delete a single fingerprint
- Highlight the finger when the sensor is touched during enrollment
- Add customized labels to fingerprints
- Devices hotpluging
However most of the code has been written considering these, and so they could
be easily implemented in future re-iterations once newer APIs are defined for
such bits.
Closes https://gitlab.gnome.org/Teams/Design/settings-mockups/-/issues/18
Add add an "updating" state to the fingerprint manager so that the UI can
adapt the widgets depending on it, as the dbus calls might be a bit slow at
times.
