According to Dan Williams, if firmware is installed the device
will disappear and reappear, and this is unlikely to change any
time soon. Just make our lives easier by removing the tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
I intended to make a few code cleanups, but I apparently forgot
to hook up _updateAccessPoint. Merge it with _activeApChanged,
which is where the notify::active-access-point signal is actually
hooked up to.
https://bugzilla.gnome.org/show_bug.cgi?id=704670
As we only reload search providers on startup or when the sort order changes,
and given the small number of search providers we'll actually load, I doubt
we'll see any speed decrease.
The simplicity of synchronous code is also much clearer, and fully avoids
all the possible bugs about in-flight requests or similar.
This also prevents issues with multiple search providers showing up at once,
which happen when multiple requests to reload search providers get called
immediately, with the existing in-flight async requests never cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
When we reload the remote search providers, we currently try to remove
all remote providers, and then re-scan. It turns out that we sometimes
remove the wrong providers from the remote provider list, causing us to
have some providers not correctly unloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=700283
When a ShellUserVerifier is asked to verify a user at the login
screen it will transparently first try to reauthenticate the user
against an existing session and then fall back to logging a user
into a new session. The former is used for user switching.
It's useful to know which type of verification is happening, so
the next button can be made to say "Unlock" instead of "Sign In" when
a user is already signed in.
This commit exports a new "reauthenticating" property on the
ShellUserVerifier that the auth prompt checks when deciding which
label to use for its next button.
https://bugzilla.gnome.org/show_bug.cgi?id=704795
If there are no messages in the queue and a user starts to
type then we can safely hide the message label since the
user has probably already read it.
This fixes a weirdness where "Incorrect Password" messages stay
around, even as the user types in the new correct password.
https://bugzilla.gnome.org/show_bug.cgi?id=704817
Similar to our ClutterContainer monkey-patching, we can add some
convenience to existing ClutterLayoutManagers:
- hookup_style() to bind layoutManager properties to CSS properties
- child_set() to set child properties
https://bugzilla.gnome.org/show_bug.cgi?id=703905
Jasper removed the ShellGlobal:stage-input-mode property after its
"last" use was removed. Adapt the (hopefully) really last use of the
property to the recent input changes.
https://bugzilla.gnome.org/show_bug.cgi?id=704095
There's quite a bit of duplicated code between the login dialog
and the unlock dialog dealing with the various signals from the
ShellUserVerifier.
This commit moves that duplicated code into the AuthPrompt.
https://bugzilla.gnome.org/show_bug.cgi?id=704707
The point of fading the icon is to make the text displayed over the
icon more legible. In RTL layouts, the text is displayed on the left
of the icon, so fading the right-hand-side of the icon doesn't work
well.
https://bugzilla.gnome.org/show_bug.cgi?id=704583
This is a regression from splitting the slider out that never got fixed.
Restore the previous (useful) behavior by adding a public API to the
slider that lets us pass an event through.
https://bugzilla.gnome.org/show_bug.cgi?id=704368
We've long had the hasWorkspaces property, but it doesn't seem like
it was ever used. Implement it so that we don't have workspaces in
initial-setup mode.
Since it's difficult to make it change at runtime with a decent set
of semantics, and we never expect that to happen, don't bother
implementing it dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=698593
commit ea02380c15 made the login
screen stop using ModalDialog. It makes sense for the unlock
code to also stop using ModalDialog, too (for similar reasons).
Now that the login screen's auth prompt code has been separated
out, the unlock dialog can use it to get the buttons and spinners
etc, that it was previously getting from ModalDialog.
This commit drops the ModalDialog usage in the unlock dialog, and
makes the unlock dialog use GdmUtil.AuthPrompt instead.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now there is a lot of duplicated code between the unlock
dialog and the login dialog.
This commit moves the login dialog's auth prompt to a separate
class, so that it can (in a subsequent commit) be used by the
unlock dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
A bug got introduced when moving the login dialog away from modal
dialog, such that it listens for escape key presses in a mouse
event handler instead of a keyboard event handler.
This commit fixes that code to correctly listen for key-press-event
instead of button-press-event.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
Right now if disable-user-list is true we show it briefly, just so
that we can fade it out to the user entry.
This commit avoids the fade in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=704471
Right now when a user types their password to unlock their session
we end up getting an unlock signal from GDM right away. We then
proceed to deactivate the screensaver before the user has a chance
to read his messages.
This commit makes sure we clear out the message queue before processing
the deactivation request.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
logind sends out an "unlock" signal separately when
verification completes and we already listen for that,
so we don't need to unlock on verification-complete, too.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
this._clearMessageQueue() is a noop when this.hasPendingMessages is
false so calling it in that case doesn't make sense.
This commit drops that call.
https://bugzilla.gnome.org/show_bug.cgi?id=704347
Add an option to limit the appSwitcher to the current workspace. For users
that use workspaces for task separation this more convient then current
behviour. While having to add an option is unfortunate there is no way to make
both groups happy as workspaces usage differes between different users / types
of users.
https://bugzilla.gnome.org/show_bug.cgi?id=703538
