The sessionList and the prompt hint are all really
part of the prompt, so we should have the code that
hides those things in hidePrompt instead of in
showUserList.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now, when a user item is clicked we remove all other users from
the list and position the item in the appropriate place on screen.
Ultimately, we're going to want to crossfade from the fully populated
list to the user prompt. Since we're going to need to show the user
avatar in two different positions we can't simply move it.
This commit leaves the user item for the user list, and instead shows
a UserWidget actor during user verification, in the same way the
unlock dialog shows a UserWidget actor during reauthentication.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Right now we very abruptly kill the login screen
and start the users session without any transition
out.
This commit introduces a fade out of the dialog and
panels.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
The latest mockups don't animate between states by
resizing actors. Instead, crossfades are employed.
This commit strips out many of the existing animations
as a first step toward implementing the new ones.
https://bugzilla.gnome.org/show_bug.cgi?id=694062
Since commit 1ae0fadbf4 we
no longer start a PAM conversation as soon as the user clicks
the "Not Listed?" button. Instead we defer starting the PAM
conversation until the user types their username.
Unfortunately, the cancel button resets the dialog back to the
user list indrectly by cancelling the current PAM conversation.
This means if the user hasn't yet entered thier username then
the cancel button doesn't work.
This commit performs a direct dialog reset in the case the
PAM conversation hasn't been started yet.
https://bugzilla.gnome.org/show_bug.cgi?id=693756
In a gdm session, we may not know what mouse orientation the user
may be in, so it makes sense to support both the left and right
mouse buttons to activate login or other items.
Additionally, add the behavior to all modal dialog items, even in
a user session, because it's unlikely that the user will right-click
on buttons, and it makes for an easier implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=688748
Due to limitations and bugs in SpiderMonkey's GC, wrapper objects
for cairo contexts and similar may not get cleaned up immediately
after repainting, leading to leaking memory. Explicitly disposing
of such objects after they're not needed can clean up large portions
of memory for cairo surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=685513
We need to do a better job of indicating login process. This can
sometimes take a few seconds (particularly if you get your password
wrong): we need to give better feedback of what's going on.
This adds a spinner next to the login button if the authorization takes
some time.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
The login dialog had these issues:
- the entry was not really disabled, you could still edit text
- the sensitivity state was not reset on verification failure
- the session list was not disabled
The unlock dialog had these issues:
- "Login as another user..." was not insensitive
- redundant password char setting, overwriting the one given by the
question
The entry insensitive style was also wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=687113
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
If I click on "Not listed?" in the login screen, I come to a username
field with two buttons: "Cancel" and "Sign In".
Clicking on "Sign In" doesn't actually sign me in though - it takes me
to the login entry. It would be better to rename "Sign In" to "Next" for
the username stage, therefore.
Gdm emit a signal to ask a question or a secret, but we can not know if
this is the last authentication question, hence we only use "Sign In"
for secret questions which improve the situation a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=687656
In some deployments showing a user list at the login
screen is undesirable.
GDM's fallback login screen has a configuration key:
org.gnome.login-screen disable-user-list false
that causes the user-list to get hidden.
This commit adds similar functionality to the normal,
shell-based login screen.
Based on a series of patches by Marius Rieder.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
Right now when a user clicks "Not Listed?" they end up
seeing a session list that gets reset after they enter their
username.
This commit hides the session list until the username has
been entered.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
For the "Not Listed?" case we will need to be able
to identify when the user has entered their username.
Once we have a way of tracking when the username is
entered, we can then defer showing the session list
too early, before the user can reliably pick a
session.
This username tracking will also be important for
implementing a disable-user-list configuration key.
If the config key gets toggled off at runtime, we'll
need to know if we're at a disruptive part of
the authentication process or not, so we know whether
we can can expose the user list right away, or wait
until the authentication conversation finishes.
Right now, we pass null in for an initial username,
and let the PAM machinery ask the user, which means we
have no good way of knowing when the username is entered.
This commit changes the "Not Listed?" code to ask the
user their username up front, before starting the PAM
conversation in much the same way we do if the user
picks a user from the user list.
https://bugzilla.gnome.org/show_bug.cgi?id=660660
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://bugzilla.gnome.org/show_bug.cgi?id=687112
If it is updated after checking, it counts the number of failures
not including the current one, so it allows one extra attempt. Instead,
by updating it before checking, we get the expected result of dropping the
curtain at the third password.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
When the user has the entered the password for the second time
and clicked OK, clear messages from the previous attempt, so any
new failure is shown clearly.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
GDM has a 'logo' key in its schema to allow distributors to add
some branding. It is currently placed above the user list, which
no longer works too well since the login screen lost its dialog
window. Display the logo in the top-left corner instead of the
Activities button instead.
https://bugzilla.gnome.org/show_bug.cgi?id=685852
Check an environment variable, GDM_GREETER_TEST. If 1, LoginDialog will
skip anything that fails outside a GDM session.
It is therefore possible to test the GDM greeter without installing it
system-wide, by attempting login as the already logged in user (uses the
same code path as the unlock dialog).
https://bugzilla.gnome.org/show_bug.cgi?id=683725
GDM's GSettings schema contains a 'disable-restart-buttons' key
that currently is only supported by the fallback greeter.
Implement support in the shell greeter as well.
https://bugzilla.gnome.org/show_bug.cgi?id=686247
Adding a group to the Ctrl-Alt-Tab popup will also add it to the
focus manager. Due to that, we currently end up with two focus
groups added for the login dialog - an explicit one for the entire
dialog, and an implicit one for the main content group.
When doing keynav, we ascend in the widget hierarchy from the
currently focused actor until we find a valid focus root, so
adding a children of the dialog as focus root breaks keynav to
any actors that are not inside the main content group.
The simple fix is to use the same group in both cases.
https://bugzilla.gnome.org/show_bug.cgi?id=684730
Now that we use a different text style for the username depending on
whether the user list is expanded or not, changing the :expanded style
before the actual transition looks disruptive. Adding the style right
before fading in other items and removing it right after fading them
out gives a better result.
https://bugzilla.gnome.org/show_bug.cgi?id=685201
Currently the layout of the password prompt differs slightly between
login dialog and unlock screen - for the former, the prompt is
displayed next to the user avatar, replacing the user name, for
the latter, it is diplayed below both avatar and name.
https://bugzilla.gnome.org/show_bug.cgi?id=685201
_moveFocusToItems seems to be called to early causing
clutter_actor_grab_key_focus not to be called.
So queue another attempt with BEFORE_REDRAW priority when
this happens to make sure we actually move the focus sucessfully.
https://bugzilla.gnome.org/show_bug.cgi?id=684650
Currently the default action is performed twice when pressing Return
in the login dialog, once in response to the entry's 'activate' signal,
and again by activating the default button. Usually this is not a
problem, as the second invocation is simply ignored, however it breaks
the case where multiple consecutive questions are asked (e.g. username
and password in the 'Not listed' case).
Fix the problem by not handling the 'activate' signal at all.
https://bugzilla.gnome.org/show_bug.cgi?id=685511
Instead of leaving the login or unlock dialogs in an inconsistent state,
catch DBus errors and show an Authentication Error message. The error
details are logged in the session logs.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
commit e333263fd6 changed fingerprint.js
to not throw an exception when fprintd is uninstalled, by adding the
flags DO_NOT_LOAD_PROPERTIES and DO_NOT_AUTO_START
DO_NOT_LOAD_PROPERTIES is correct. Loading the properties is what makes
it fail at initialization time when not installed. DO_NOT_AUTO_START is
not correct though. It means fprintd will never get activated implicitly
when we need it.
This commit removes DO_NOT_AUTO_START thus making fprintd start when we
need it, but not fail at initialization time when not around.
https://bugzilla.gnome.org/show_bug.cgi?id=683131
Instead of showing a notification, add a small message immediately
below the entry, and give the user two more attempts to login,
before going back to the welcome or lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
Ensure that all async callbacks check and ignore G_IO_ERROR_CANCELLED.
Ensure that all runs of authentication have their own GCancellable, so
that .begin() can be called multiple times on the same user verifier.
Check for fingerprint reader when beginning authentication, and not
when reset by GDM.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
Otherwise the second attempt tot login after pressing "escape" key
on the login "freeze" and raise an exception about IOError operation
cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=681537
The fingerprint message is useful for users that click their
names in the user list to let them know if fingerprint login
is available.
This same place on screen (below the login entry) can potentially
be used for other messages as well.
This commit changes the variable and style names surrounding
this feature to be more generic.
A subsequent commit will leverage this functionality to provide
a hint on how to log in to the local enterprise domain controller
(if relevant).
https://bugzilla.gnome.org/show_bug.cgi?id=681975
Various code around had different paths for ConsoleKit and
logind. Consolidate it by making an abstract class that all
callers can use, which hides the implementation details of the
two daemons.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
In preparation for accessing it in the screenshield, factor out
common code for ConsoleKit and Systemd.
Also, clean up ConsoleKit manager, as the daemon is required in
a non systemd installation. In particular:
- We allow it to be autostarted at session startup (or really,
we expect it to be already there, started by GDM during session
opening).
- We no longer silently assume that the session is active if
it can't start.
https://bugzilla.gnome.org/show_bug.cgi?id=682096
GetUserVerifier can only be called from the greeter session,
and fails with AccessDenied in all other cases. Also, calling it
hides the real error from OpenReauthenticationChannel, which
instead should be logged.
https://bugzilla.gnome.org/show_bug.cgi?id=680750
Unlike the fallback gdm UI, we do not indicate in the user list
whether a user already has an open session or not. This information
is useful, so use a spotlight effect similar to the running-app
indicator to mark logged in users.
https://bugzilla.gnome.org/show_bug.cgi?id=658185
We want to style user list items differently depending on whether
the list is expanded or shrunk; instead of manually updating the
items' style, we can just expose the :expanded style on the list
itself and use that in the CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=658185
The current animation time of two seconds may result in some
confusion, as the reason of the behavior only becomes apprent
when the auto-activating item becomes visible; make the animation
a lot faster and ease it out a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=660913
Until the recent style changes, the same element was used to indicate
both item focus and progress for timed logins. As focus is now indicated
by the item's background style, rename the indicator from focusBin to
timedLoginIndicator and make some minor adjustments to better fit the
new style:
- move it next to the icon below the text
- give it a white color and a shadow
- update animation to grow from the left instead of the center
https://bugzilla.gnome.org/show_bug.cgi?id=660913
Rather than changing the text color to indicate hover and an underline
to mark the focused item, use the same semi-transparent white background
as in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=660913
The design calls for the curtain to appear in the gdm greeter too.
Implement this by having the screenshield manage the login dialog
(delegating its creation to SessionMode).
https://bugzilla.gnome.org/show_bug.cgi?id=619955
Add 'default' parameter to setButtons, that controls the binding
of Return (unless overridden) and applies the 'default' pseudo-class.
Currently it has no effect, but it will start having after the
login dialog redesign.
https://bugzilla.gnome.org/show_bug.cgi?id=619955
When setting an explicit size as we do currently, rounding errors
(for instance introduced by padding not specified in pixels) may
affect the parent's size allocation, e.g. making it shrink or grow
each time the size is reset.
Rather than taking care of possible rounding errors, set up focusBin
to take up the available width and use scaling for the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=675076
When GDM was moved over to GDBus it dropped the libgdmgreeter
library and introduced a new libgdm library with a somewhat
different API.
The main differences in the API are:
1) open_connection is now implicit and automatic
2) conversations don't need to be started explicitly, they're
started just-in-time when verification is requested
3) The functions are split up between the client, and new
helper objects that correspond to the dbus interfaces
they were generated from (one for user verification,
one for greeter specific operations, and a couple more
that aren't used by gnome-shell).
4) libgdm supports reauthenticating in an already running
session, so user switching should now affect the users
session more like screen unlocking does.
This commit moves the shell over to the new library.
Based on work by Giovanni Campagna <gcampagna@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=676401
When using dbus-glib, single return values were special-cased to
be returned verbatim rather than as array with a single element.
This is no longer true since switching to GDBus, so fix the places
where the change was overlooked.
https://bugzilla.gnome.org/show_bug.cgi?id=678852
We seem to have a lot of code that does something along the lines of:
if (condition)
actor.show();
else
actor.hide();
ClutterActor already has such a thing for exactly this purpose: the 'visible'
property. Use it instead of the mess above.
https://bugzilla.gnome.org/show_bug.cgi?id=672272
ConsoleKit is obsoleted by systemd-logind. Accordingly, port
the current CK code to systemd. In order to be nice to
the Debian people fall back to CK if systemd is not found,
so that the code makes the best of whatever it runs on.
Commit 25948f214e replaced the old hardcoded scaling behavior of
background-images with the CSS-compliant option to control that
behavior with the background-size property. Fix some fallout from
the changed default scaling behavior.
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Users don't expect the bullets they just typed into an entry
field to disappear as soon as they hit enter.
Instead, they want the dialog to become insensitive during the
authentication process, so that it's clear that what they typed
in is being processed.
https://bugzilla.gnome.org/show_bug.cgi?id=657894
Right now we show "(or swipe finger)" at the user login prompt
any time we detect a fingerprint reader.
Checking for the presense of a fingerprint reader isn't really
sufficient for knowing if it is appropriate or not to show the
message, though. Often, a user's fingerprint won't be enrolled
in the system even if the machine has a fingerprint reader.
In this scenario, we end up in a situation where the code will
fade out the message right after fading it in, or worse, fade
out the message while fading it in.
The former case looks flickery and bad, and the latter case
causes the login dialog to lock up since it never completes its
"show prompt" animation and we don't procede with the login
process until after that animation.
If a user is enrolled in the system, the fingerprint pam module
tries to tell the user to swipe their finger. We never show the
user that message because it's redundant with our own "(or swipe
finger)" message and because it uses techy words like "UPEK" and
"TouchStrip".
This commit changes the code to defer showing "(or swipe
finger)" until the fingerprint pam module forwards us its own
message. This makes it less likely we'll show the message when
fingerprint login won't work, and also removes the fingerprint
animation from the critical path "show prompt" animation.
https://bugzilla.gnome.org/show_bug.cgi?id=660492
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
This commit adds the ability to log in with a fingerprint instead
of a password (assuming the user is enrolled and fingerprint
isn't disabled via gsettings)
https://bugzilla.gnome.org/show_bug.cgi?id=657823
If there's no scrollbar in the user list it grows as the
user arrows around. This is because it wasn't taking
padding into account when computing its destination size.
https://bugzilla.gnome.org/show_bug.cgi?id=658469
Making users have to log in to power off the machine isn't a good idea.
This commit adds a power menu similar to the one in the fallback greeter
which offers 3 items:
- Suspend
- Restart
- Power off
https://bugzilla.gnome.org/show_bug.cgi?id=657822
The session list is supposed to hide itself if
1) the user is already logged in
2) there is only one xsession file installed
There was a bug causing 2) not to work.
This commit fixes that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=658423
This commit adds GDM session support.
It provides a user list that talks to GDM,
handles authentication via PAM, etc.
It doesn't currently support fingerprint readers
and smartcards.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
In order for transformation animations to look good, they need to be
incremental and have some order to them (e.g., fade out hidden items,
then shrink to close the void left over).
Chaining animations in this way can be error prone and wordy using just
Tweener callbacks.
This commit adds a new set of classes to help:
- Task. encapsulates schedulable work to be run in a specific scope.
- ConsecutiveBatch. runs a series of tasks in order and completes
when the last in the series finishes.
- ConcurrentBatch. runs a set of tasks at the same time and completes
when the last to finish completes.
- Hold. prevents a batch from completing the pending task until
the hold is released.
The tasks associated with a batch are specified in a list at batch
construction time as either task objects or plain functions.
Batches are task objects, themselves, so they can be nested.
For now, these APIs are temporarily getting staged in a gdm/ specific
subdirectory so they will be available for use by GDM. They aren't
specific to GDM, or even to doing animations, though, so the API may eventually
move in some form or another to a more general location. Alternatively, the
APIs may ultimately get dropped entirely and replaced by something else.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
