GNOME Bugzilla – Bug 687112
Login button should be insensitive until text has been entered in the password field
Last modified: 2012-11-05 19:33:18 UTC
You can't login until something has been entered in the password field. We should therefore make the login button insensitive until you have entered some text: https://dl.dropbox.com/u/5031519/gnome-shell/login/1-incomplete.png
Created attachment 227561 [details] [review] Patch
Looks good to me. Just needs code review by someone who understands code. :)
Review of attachment 227561 [details] [review]: Yes, this looks fine, but before we declare this fixed, we need a similar patch for the login dialog too.
Created attachment 227808 [details] [review] Patch for both the unlock and login dialogs Oops, I totally missed that. Here's a patch with the required changes on both dialogs.
Review of attachment 227808 [details] [review]: This seems to have some indentation issues.
Created attachment 227809 [details] [review] Patch without tabs Sorry, I just saw there was tab vs space issues.
Review of attachment 227809 [details] [review]: Tested, looks fine and works fine. It is ok to commit as is if you want, or you can merge it, but at some point LoginDialog needs the same sensitivity tracking that UnlockDialog does, i.e. the login button should be insensitive while verification is in process (after answerQuery and before the next _askQuestion)
Giovanni: that's exactly what I was about to work on today :) I let it rot a bit as I wanted to finish 657315 before, so I could wait for designers input between my tasks.
Giovanni: I meant you can commit this one for me, I'm working on 687113, which is the other part of the sensitive work. Allan split the bugs to simplify sharing, but the entry sensitivity should have been part of this bug from the start.
Given that the login dialog and unlock dialog use the same UI, it probably makes sense to make it into a shared widget that does some part of the PAM step, and has a signal for handoff (raise modal, defer to gdm)
That would be good to commit this patch before nonetheless, to avoid an additional rebase :)
Yeah, it was just an off remark.
Awesome work once again, Stéphane. It would be cool if someone could file the bug about merging the login and unlock dialogs.
(In reply to comment #10) > Given that the login dialog and unlock dialog use the same UI, it probably > makes sense to make it into a shared widget that does some part of the PAM > step, and has a signal for handoff (raise modal, defer to gdm) I might disagree with that. Yes, they look similar, but they are really very different in the implementation and actor hierarchy, so to unify them I'm afraid you'll get a generic monster with no actual benefit to the two codebases.
(In reply to comment #14) > I might disagree with that. Yes, they look similar, but they are really very > different in the implementation and actor hierarchy, so to unify them I'm > afraid you'll get a generic monster with no actual benefit to the two > codebases. Well yes, they're different in the implementation and actor hierarchy. My solution is to remove that.
Created attachment 228182 [details] [review] Revert "panel: programmatic anim. control of AnimatedIcon" This reverts commit e04a4c39231ea1418591446d9b98aad4d7bcd2de. This commit exposed an already-existing race condition in the panel animation code that caused the shell to crash for some people.
Comment on attachment 228182 [details] [review] Revert "panel: programmatic anim. control of AnimatedIcon" Attachment 228182 [details] pushed as d88002c - Revert "panel: programmatic anim. control of AnimatedIcon"
*** Bug 687653 has been marked as a duplicate of this bug. ***