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
We need to make sure that we reset the opened submenu when we close the
submenu, not trick the toplevel into thinking a closed submenu is the
currently opened menu.
https://bugzilla.gnome.org/show_bug.cgi?id=704336
We don't set :visible on the scrollbars, but use booleans to track
if they are visible. Thus check the booleans instead of the actor's
properties when allocating the scrollbars.
https://bugzilla.gnome.org/show_bug.cgi?id=704265
At some point the Not Listed? button was moved to align it better
in the login screen. That nudging made the "Log in as another user"
button (which uses the same style class) align worse.
This commit removes the padding at the unlock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=704318
Make the notifications wider and adjust the padding so they
aren't as tall. Also make the corner radius consistent with the
rest of the theme.
This makes the notifications look better, is more space
efficient, and is consistent with the latest mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=702305
This way, if a parent is insensitive, all children will be, too.
Though PopupSubMenus will be forced closed, PopupMenuSection needs
the propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Doing it at the end has confusing semantics, especially as there is
this point where isOpen is true, but the corresponding open-state-changed
has not been emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Use ClutterActor.allocate_align_fill() so we don't have to do
this math ourselves. At the same time, clean up the RTL handling
so that it's easier to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
It seems this behavior at one time was intentional, but I (along with
the designers) think it looks ugly having the menu having its insides
shrinking and shifting around while fading out of existence.
There's two cases where we currently explicitly try to animate the
submenu closed -- when an item is clicked inside the submenu, and
when the toplevel closes. This removes both of those.
The user expectation is that submenus will be closed the next time the
toplevel is open even if they were open before, so force submenus closed
when the toplevel finishes fading out, without any animation.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
As the aggregate menu will be built out of sections from each
of the menus, we need to ensure that activating an item in one
of these sections can close the main menu, even when it is not
a menu item. The new API also needs to be flexible enough to
ensure that animations can be controlled, like the buttons that
lock the screen or launch a new session.
Port the user menu to use this new API as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702539
Now that we preallocate space for the prompt message there is
a lot of loose space between the entry and the buttons.
This commit helps tighten things up by getting rid
of the large top padding set above the login buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=702308
