Usually, logging in or unlocking the session is made asynchronously,
and AuthPrompt properly manages which entry is currently visible.
External code don't rely on any specific entry to be set, since it
is AuthPrompt's responsibility to select the correct one to be shown.
However, there's one specific case where AuthPrompt must preserve
the password entry: on reset. The reset code preserved whatever
entry was currently displayed, but after fe69dacaf1, it always
changes to the username entry.
Make sure to show the password entry on reset.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the past, the session menu button was part of the auth prompt widgetry,
so we didn't have to manually hide it when showing the user list. However,
now it is part of the login screen itself.
Hide the session menu button when the user list is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/999
In the common case where we only have a single unread notification
from a particular app, the count doesn't add useful information.
Reduce clutter a bit by only showing the notification count if we
have at least two.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/997
Instead of alphabetical ordering, sort the widget stylesheets
from more global to more local while grouping related things.
This helps reduce unintended behaviors and ugly overrides and
make styling and debugging easier.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/938
Clicking or typing to reveal the auth prompt are good options for
mouse/keyboard workflows, but awkward on touch devices. Now that
we have SwipeTracker, adding corresponding gestures support is
easy, so do just that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
The current transition between clock and auth prompt uses a simple
crossfade.
"What kind of spatial model is that?!"
T.B.
Root the transition a bit more by adding translation and scale to
the animation.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/972
Hiding the Caps lock warning label changes the layout of
Auth Prompt. This is specially noticeable when logging in
with unlisted users, where we change the visibility of this
label after typing a username, and the whole user widget
moves a bit.
Change the Cap lock label's opacity instead of hiding it.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, when a null user is passed, we don't add any
username label. That makes the layout of user and no-user
cases inconsistent.
Add a ghost label with no opacity to mimic the username
label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, AuthPrompt is connecting to its own 'next' signal
signal to react to any of the entries being activated, and do
some actions like starting the spinner and answering the PAM
question.
Refactor this code into another method, and don't connect to
our own signal.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Unfortunately, the question that is displayed comes directly
from PAM. It usually is just "Password:", which comes from
pam-unix, but other questions can be set, usually with the
colons, since they are crafted with a CLI workflow in mind.
Manually drop the colons from questions asked by PAM. This
is also done by the PolKit agent, which shows how the stack
is fragile, but it's what we have for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
This is a regression from the transition to password entry. Both
entries need to be connected to the relevant signals, otherwise
username-based login won't ever work.
Connect both the text and the password entries.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Currently, there is a dedicated label above the entry to
display the question text. According to the new mockups
for the lock screen, this label doesn't exist; instead,
the question is set inside the entry itself, as a hint
text.
Set the questions as hint texts of the entry, and remove
the now unused label.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
If username-based login flow is followed, we need a default avatar
for the userWidget. Hence, check if the user passed to userWidget
is (null) which implies a username-based login flow.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
