search

samcday / phrog

🐸 Mobile device greeter
GNU General Public License v3.0
10 stars 0 forks source link

Improve input ergonomics #28

Open samcday opened 2 months ago

samcday commented 2 months ago

Currently the whole keypad is being made insensitive whilst greetd roundtrips are in flight. This is annoying if you start typing your password from the user selection. Some of your input might have been dropped because the insensitive period is fairly short (a few dozen ms) and happens during page transition.

Instead, it should just "delay" the submit handler if fired, such that the submit text is changed to "aight k00l homie 1 sec tho fam" (maybe with a spinner? those are still socially acceptable right?) and that's when the whole page can be made insensitive.

samcday commented 2 months ago

This will likely require some upstream changes so I've labelled it as such.

Currently the lockscreen API is trending towards a higher level approach that hides away the underlying widgets and offers some straightforward APIs on top of them. What we'd like to do in this issue is stuff like:

We could add high level APIs for those, or maybe it's better to just offer up a GtkButton* phosh_lockscreen_get_submit_button() API. I'm curious what you think about this @agx

The other option here is to go as light as possible on upstream changes. The submit handler could simply start a Future and silently abort if one is already in flight. I think that would be possible today, and I'll explore that when I have time.

Even so, IMO it's preferable to have more control over the visual feedback presented to the user when :frog: is roundtripping greetd.

agx commented 2 months ago

Even so, IMO it's preferable to have more control over the visual feedback presented to the user when 🐸 is roundtripping greetd.

I think the visual feedback should stay in line with the visual feedback the user gets when phosh itself handles the unlock as otherwise it would be confusing to the user (as most uses won't know that the greetd unlock is a different process then what happens when they unlock after a screen lock).

Or are there situations where we'd want it to be different?

samcday commented 2 months ago

I think the visual feedback should stay in line with the visual feedback the user gets when phosh itself handles the unlock as otherwise it would be confusing to the user

Agreed.

I do think there's some subtle differences though and the UI does need to reflect that. I'll get into that in a moment.

But in this particular case I mostly just got myself confused with the button API stuff. Please disregard all of that. :frog: already (and will continue to) do what PhoshLockscreen default submit handler does: make the whole lockscreen insensitive while round tripping the submit.

Or are there situations where we'd want it to be different?

The difference is that :frog: needs to do roundtrips that show appropriate UI state (and error cases) that the Phosh lockscreen for a logged-in user does not need to handle.

In particular, greetd sessions, much like the PAM conversations they wrap, are an "active participation" thing. When you start one, it might bring up the fingerprint scanner with an idle timeout. So we only want to call greetd CreateSession when the user has navigated to the keypad page (or tapped on a user, which navigates them to the keypad page).

The main friction point around this specific behaviour is best explained in this issue I just opened upstream: https://gitlab.gnome.org/World/Phosh/phosh/-/issues/1113

Beyond that, I think I should be able to achieve what I want without further upstream changes.

Specifically, I need to rework the greetd session setup to not make the whole lockscreen insensitive while that request is in-flight. Instead, I'll delegate that call to a Future, and make sure to block on that Future's success in the submit handler.

I want the greetd session to be established as soon as possible. The lockscreen decides which "page" it's on based on rounding of the carousel value, so ideally the signal for page property fires when the carousel position goes from 1.50 to 1.51. In many cases this will mean that the greetd roundtrip happens while the carousel is still animating.