Currently, prompting for the username on the login screen is done
"out-of-band". This leads to subtle bugs where we're trying to
integrate two different state machines, or interpret results from
one state machine as part of another.
It also complicates the logic, as the ability to know whether we
need or want a username is currently in the UI layer rather than
the logic layer.
Move this into the verifier proper.
We still need to expose smartcardDetected to determine whether to
prompt for a username. This part is another hairy mess of signals
and layer violations that will need untangling, but we'll get there...
The idea here is that the ShellUserVerifier does all the logic of
identifying the user, and the AuthPrompt is simply the UI on top
of it.
Thus, it makes sense for more of the state machine to be driven by
the ShellUserVerifier.
This will become more apparent in the next commit.
When we emit the 'cancelled' signal if we were previously verifying,
we'll always emit a 'failed' signal. LoginDialog doesn't care about
cancelled, only UnlockDialog cares about both, but it does the same
thing for both, so there's no reason to have the extra signal.
Do a reset at initialization time.
Technically, this isn't needed, since to start the process we'll need
to reset(); anyway after all the signals have connected, but this helps
the code be clean.
If we fail to verify, and don't have any pending messages, we'll retry
or cancel, which will cause a state change to VERIFYING or NOT_VERIFYING,
and then change the state again to VERIFICATION_FAILED, messing up our
state machine.
Loading the user list can be expensive, for instance when there is
a large number of users and/or their avatars have to be fetched over
the network. In case the user list is disabled anyway, there is no
point in doing that work just to hide it, so stop doing that.
https://bugzilla.gnome.org/show_bug.cgi?id=725905
When the user changes the active day by mouse click or keyboard focus
plus key press on a day in the grid, always move the keyboard focus to
the newly activated day.
This basically restores functionality that was introduced in commit
31478e9fb4 but got lost again in the re-factoring in commit
cc4659f5c6.
https://bugzilla.gnome.org/show_bug.cgi?id=725606
Having to go through import.gi is awfully inconvenient when one
is using the looking glass as a quick gjs console, and we're
already importing all sorts of stuff there.
https://bugzilla.gnome.org/show_bug.cgi?id=725832
Don't forget to rebuild the calendar when changing the setting
'org.gnome.shell.calendar show-weekdate'. This wasn't happening anymore
and changing the setting resulted in a calendar without the days
grid.
https://bugzilla.gnome.org/show_bug.cgi?id=725533
Once you start navigating between months, you can't return to the
current day. However, the current day is always displayed above the
calendar grid. Fix this by making the current date clickable; when
clicked, the calendar grid jumps back to that day.
https://bugzilla.gnome.org/show_bug.cgi?id=641366
The profile name is most often not useful (because it's an
autogenerated string like "Wired Connection 1"), and even when it
is, it's already available in the submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=725586
While the named commit was correct for VPN connections, it didn't
work correctly for the initial secrets requests like when connecting
to a new access point. In that case, secrets *should* be requested
when none are found, but only if interaction is enabled. The
bits of 17726abb which removed checking secrets against the hints
*were* correct, but 17726abb removed too much.
Also, to ensure passwords don't get inadvertently cleared when
simply reading them from the keyring, don't save passwords
unless something might have changed.
https://bugzilla.gnome.org/show_bug.cgi?id=724779
