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 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
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
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
A PanelMenuButton added to the top bar might not be visible at all
times. If it is hidden while the corresponding menu is open, we
currently don't do anything at all, e.g. the menu remains open
pointing to an arbitrary location in the top bar.
Instead, close the menu automatically in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=703540
The event catcher that covers the entire primary monitor during
transitions is currently inside a BoxLayout, relying in its
odd support for fixed position actors.
We already have a proper stack widget in place, move it there.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
Currently lookingGlass relies on some odd BoxLayout behavior, which
allows children to use fixed positioning without affecting the parent's
size request. As this behavior is scheduled for removal, add the
looking glass dialog directly to Main.uiGroup.
https://bugzilla.gnome.org/show_bug.cgi?id=703808
