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.
This is a wrapper to read the state of the fingerprint devices and to check
asynchronously whether we have them and if they have enrolled prints we can
use to log-in.
Goal of this commit is to not overwhelm UI when a lot of printers is added
to CUPS. You can reproduce this situation when you add e.g. 30 printers using
lpadmin. Th UI stops to respond for some time.
To do so, the printer entries are not deleted every time there is a request
for updating of the list of printers but only new printer entries are added
and printer entries of deleted printers are removed. Other printer
entries are just updated by new method pp_printer_entry_update().
Which, by the way, is almost whole taken from pp_printer_entry_new().
This needed to add sort function for the list of printer entries. It sorts
printers according to their names not taking case into account.
In the similar manner, the filter function was extended to not show printers
which are being deleted. This needs a list of names of deleted printers
which we keep until they are really deleted.
One important thing here is the "reference" object which points to the panel
itself via its "self" key. We pass this object to the pp_printer_delete_async()'s
callback so it knows whether it can remove the printer's name from the list
of deleted printers (once the panel is being destroyed it clears the key itself).
malcontent[1] is parental(or admin) controlled interface which
can restrict a application's visibility and interactivity for a
standard user. Hence, if the current uid has any restrictions
on its installed applications, filter them out from the applications
panel.
Make the malcontent support enable or disable by setting it up as
a build-time meson option.
[1]: https://gitlab.freedesktop.org/pwithnall/malcontent/
Remove GSource used for real deletion of a printer when
the "Undo" notification was dismissed.
Also set the timout id of the notitification to 0 when triggered.
Replace cancel_notification_timeout() with one line.
The issue fixed here could be reproduced this way:
1) Open Printers panel
2) Remove a printer
3) Press back button to go to overview
4) Wait 10 seconds
5) Return to the printers panel
6) Close gnome-control-center
Result:
Critical warning on removal of non-existing GSource
Callback for handling of "notification-dismiss-button" got its
parameters swapped. This resulted in crash when user closed
notification about deleted printer.
This commit converts the on_notification_dismissed() function
to accept swapped arguments as was probably intended.
In the screen lock tab we add a "Forbid new USB devices" entry with a
switch to enable or disable said protection.
The actual USB protection is handled by gnome-settings-daemon and
USBGuard.
We use the "Available" property of gnome-settings-daemon to check
if we are able to offer the USB protection (i.e. USBGuard is
installed with the minimum required version ecc..).
If the host doesn't met the requirements we hide the USB
protetion row entirely.
Given the fact that the always on protection benefits are very slim we
decided to give just an on/off switch that by default controls the
"with lock screen" protection level.
There are devices with more than 10 enroll stages we should handle, so
instead of hardcoding a grid of images, let's just build this dynamically
using a flowbox
Don't make the UI to block while deleting the saved prints (that might take
some time, especially for devices with internal storage) but just use a task
with a thread that:
- Mark the fingerprint row as unsenstive
- Calls the method to delete prints
- In the same thread, calls the method to fetch the updated informations
- Returns in set_fingerprint_row_cb where we update the UI again
Again this would be nicer to be done just using async calls but this is
something to do in some bigger refactor.
Don't load the fingerprint information all the times we update the view, but
load it during initialization only.
The fingerprint state in fact can only change because we requested it
through the dialog that we control already and that would update the
relevant widgets state anyways.
Also, given that the fingerprint settings are visible for the current user
anyway, we can track this only with a simple boolean, instead of using a set
of UIDs.
When opening the user panel we g-c-c performs lots of sync operations that
may cause a noticeable slowdown, especially when a fingerprint device is
available, in fact set_fingerprint_label() call leads to:
- DBus sync request of the system bus
- fprintd dbus-activation
+ This leads to sync opening of all the devices, that might also cause
a slowdown, depending on the devices drivers
- Dbus sync calls to the device to get the list of enrolled fingerprints
Only after we've a reply, we update the g-c-c UI and continue the execution.
The fingerprint dialog code would need some global refactor, but to fix this
without big changes, let's just use GTask that runs a thread in wich we do
all the sync operations, and once done we finally update the widget state.
