We currently will always allocate the user list's preferred size, so it
will grow indefinitely and never scroll; limit the height instead to
get the desired scrolling behavior when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=754525
When the user successfully types their password, we should hide
the spinner from the button well right away, so it doesn't
consume resources until reset (which may happen significantly later
if the user is vt switched away)
https://bugzilla.gnome.org/show_bug.cgi?id=753891
The code previously tried to stop spinner after it was hidden, but
due to an incorrect check was only stoppig it after it was shown.
Also, it was only stopping after hiding due to an animation, and
failing to stop it in the non-animated case.
This left the spinner hidden and running while VT switched away
from the login screen, only stopping when the auth prompt was
reset when switching back.
https://bugzilla.gnome.org/show_bug.cgi?id=753891
* switch to a one-column layout (and adjust strings/widths
accordingly
* remove separator before system menu
* add link to account settings to user submenu for consistency
https://bugzilla.gnome.org/show_bug.cgi?id=751377
Since commit 79c04c93e4, we launch Polari instead of Empathy when
activating a chat notification for an IRC channel. It therefore makes
sense to follow Polari's notification policy for those notifications
rather than Empathy's.
https://bugzilla.gnome.org/show_bug.cgi?id=752881
We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.
This fixes a bug introduced in commit 3c8c5a5570 that leads to the
user session crashing when the login screen is reactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
We fade out the authentication prompt when a user successfully
logs into a user session. We reset it and fade it back in when
the user switches back to the login screen VT.
The problem is, we only fade it back in if the auth prompt status is
VERIFICATION_SUCCEEDED. It's possible for it to be NOT_VERIFYING
if the authprompt gets reset for some other reason in the interim.
This commit changes the check to be more precise. We now only skip
the fade-in, if we're already faded in, and we only skip the reset if
we're already reset.
https://bugzilla.gnome.org/show_bug.cgi?id=753181
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
