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
Allow vertical orientation for the userWidget so that the user-avatar
can be centered and user's name can be placed below it. The plan
for 3.36 is to use this vertical userWidget layout for both lock
and login screen.
The userWidget is also used while creating the user-selection list
at the login, hence we still need to keep the horizontal layout
for userWidget in place.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922
Since the blur sigma decides how many pixels get factored in when
blurring and setting a scale factor increases the background texture by
that factor, the sigma value should also be multiplied by the scale
factor.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
There is nothing else to be focused in the lock screen itself -- the
top bar is already handled elsewhere, and the dialog manages itself
now.
Remove the lock screen group from the Ctrl-Alt-Tab manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
AuthPrompt is the set of actors that contain the user avatar,
the username, and the password entry. With the removal of the
screen shield, the unlock dialog (be it UnlockDialog or the
LoginDialog) is always created, and in the case of UnlockDialog,
so is the auth prompt.
This is problematic, though, since for passwordless accounts,
the simple act of creating AuthPrompt authenticates the user,
and lifts the lock screen.
Create the AuthPrompt on demand in UnlockDialog.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
As per the latest lock screen mockups, critical notifications must have
a more prominent, solid color.
Add a .critical style class to critical notification bubbles, and make
them darker.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Now that the screen shield is gone (at least, as it used to
be), the corresponding session mode is not necessary anymore
as well.
Remove the 'lock-screen' session mode, and the corresponding
CSS.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Pretty much what the commit title says.
This gives the lock shield actor another role: instead of
being the interactive screen shield, make it the invisible
actor that prevents interacting with windows while the
unlock dialog is sliding down.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
The 'onPrimary' argument was being passed to dialog.open(). Turns out,
neither UnlockDialog nor LoginDialog use this parameter.
Remove the unnecessary 'onPrimary' parameter, and cleanup the related
code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
