GNOME Bugzilla – Bug 685307
Blue login button oddities
Last modified: 2012-11-20 20:26:18 UTC
If I press the button with the pointer and release, the button appears pressed but then the label changes to a dark color for a short while. If I press the return key, the button doesn't appear pressed and the label changes to the dark color. Pressing the button with either the pointer or the return key should simply result in the button having a pressed appearance. Afterwards, it should immediately return to normal.
The button and the entry are insensitive until the auth is done to avoid multiple clicks and hammering the auth system. We might try to restore the sensitivity as soon as auth succeeds, before the curtain animation starts, but maybe the entry/button can still be used for an instant and that would require to use a "looking glass" to stop input on them? But more generally, isn't it because the button theming does not really make it look like it's disabled? It could be darken more globally (darker blue). I'd like to test on other mobile devices, but I think even on touch screens it makes sense to disable the input since the auth might take time.
Ah, I hadn't realised that the button is going insensitive! So, there are a few things we can do here: 1. Improve the insensitive button styling so it actually looks insensitive 2. Make the password entry box insensitive while authorisation takes place 3. Put a progress spinner next to the login button if authorisation takes longer than about half a second Mockups: * https://dl.dropbox.com/u/5031519/gnome-shell/login/1-incomplete.png * https://dl.dropbox.com/u/5031519/gnome-shell/login/2-sensitive.png * https://dl.dropbox.com/u/5031519/gnome-shell/login/3-progress.png
Also included in the mockups: 4. Make the Login button insensitive when there isn't any text in the password field We can tackle these as separate bugs, so I've filed bug 687110, bug 687112 and bug 687113. I'm leaving this here as a tracker bug.
Unfortunately, I think having split this in multiple bugs will make it more difficult to handle because the patches work on similar areas. If it is easier for maintainers I can attach all the patches on this tracker bug as a patch series that is easier to apply, otherwise I'll need to rebase between each patch application.
(In reply to comment #4) > I can attach all the patches on this bug, otherwise I'll need to rebase > between each patch application. It's OK to have dependencies between bugs, so both individual bugs or a patch series are fine - basically pick whichever you prefer.
All done. Stéphane is my hero.