Currently user can choose avatar only from local files.
This prevents users from loading a file at a remote location.
Changes made include:
1. Setting local-only property to false in `cc_avatar_chooser_select_file`
2. Getting file uri and creating a GFile from it.
3. Reading the GFile into an input stream.
4. Loading image from this stream.
Closes: #813
This allows querying the parental controls status of other non-admin
users once the panel is unlocked.
Implication is not recursive in polkit, so it’s unfortunately not
sufficient to just imply
`org.freedesktop.MalcontentControl.administration` (which itself implies
all the other actions).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
For sake of simplicity we were just releasing a state once we got a
callback, however during the handling of the callback itself we are
still technically under that scenario, so we should release a state only
after the callback is completed.
This is more relevant now since when converting errors to human readable
strings we check the state we are in, and so we need to ensure that this
state is preserved until this point.
In case the device got disconnected while enrolling we should not try
to stop or unclaim it, but indeed show an error related to the device
not being available.
To get this we only have to remove the enrolling and claimed states now
Use flags to track the dialog actions state so that we can:
1. Remove multiple flags to track specific states
2. Prevent starting again an action we're still waiting for completion
3. Handle global visual elements (such as the busy spinner) correctly
Specifically point 3. allows to ensure that when doing concurrent
actions such as prints listing and device claiming, we will stop the
spinner only once all the operations are over.
We were a bit too permissive in handling the AlreadyInUse error during
claim, as we assumed it was always us causing it instead of properly
handing the case a device was already claimed by another caller.
So to ensure this is the case we need to avoid multiple calls to claim
until we've finished one.
Unfortunately we can't rely on a cancellable here as we may end up
cancelling the request that succeeded and we'll only get an
AlreadyClaimed error without know if it was us succeeding.
Fixes: #1201
We unset the local device early when releasing it, so use the one we
get the callback instead of relying in the private instance that has
been already cleared.
Rather than hiding the ‘Add User’ button when the panel is locked, show
it in an insensitive state. This gives the user a hint that in order to
add a new user, they will need to unlock the panel.
See: https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/26#note_705945
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Highlight that the panel needs to be unlocked in order to add new users.
Currently, while the panel is locked, it’s not at all obvious how to add
new users.
In particular, this helps improve the flow from the parental controls
application, which opens g-c-c to allow new users to be added.
See: https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/26#note_705945
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s possible for `gdk_cursor_new_for_display()` to return `NULL`. It’s
OK to pass `NULL` to `gdk_window_set_cursor()`, but not OK to then unref
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
A duplicatend and translated string could be passed to gettext another
time. If that string can be translated, then a static string would be
returned rather than the const one, causing an invalid free.
Fixes: #1149
We already had the machanism to show/hide the button based on the number
of camera devices detected. We were just not checking for that at
startup.
Fixes#1087
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.
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.
