Logind provides a Suspend method, which we should use instead of
the UPower API when available. Expose this in loginManager, using
the UPower API for the ConsoleKit implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=686482
Change the layout strategy to be more like the mockups. With less than
two rows of windows, we try to fit every window in a non-aligned situation;
with more than three rows of windows, we try to fit every window in an
aligned situation.
Based heavily on a patch from Pierre-Eric Pelloux-Prayer <pelloux@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=582650
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
Ouch. This went unnoticed for a long time as by default (using
dynamic workspaces) only one workspace is added at a time, which
happens to work fine.
https://bugzilla.gnome.org/show_bug.cgi?id=686487
Hide workspace switcher if dynamic workspaces is disabled and number of
workspaces is set to one only, since the user is bound to only one workspace
and showing the switcher is redundant.
Signed-off-by: Seif Lotfy <seif@lotfy.com>
The same logic as for commit 1f30670c1d applies to the case
where we lock the screen before suspending - we don't want the
menu to jump to the opposite screen side to fade out, so remove
the animation altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=686484
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
Due to a typo, it never worked correctly. After a fix-up to the appropriate
method, the behavior is suboptimal, as the buttons only fade in the first time
the modal dialog is constructed. Just remove the fade-in behavior, rather than
keeping this non-working code around.
https://bugzilla.gnome.org/show_bug.cgi?id=677426
This is a workaround for power users for the "Show Apps" button
placement being too inconvenient to press at the bottom of the
dash favorites list.
Unity also uses Super+A to show the Apps lens.
https://bugzilla.gnome.org/show_bug.cgi?id=685738
Currently the label for the show-apps button is only updated during
drag operations, so after an item is successfully dropped on the
button, the label will still read "Remove from Favorites".
Fix this by resetting the label on drag-end.
https://bugzilla.gnome.org/show_bug.cgi?id=684627
If esc is pressed twice in succession in the unlock dialog, the curtain
is cancelled, but the dialog is cleared after the first esc cancels it,
and it's not destroyed and recreated.
https://bugzilla.gnome.org/show_bug.cgi?id=685441
The interface was declared to take an unsigned integer instead
of a boolean, as gnome-screensaver does. Due to this,
gnome-screensaver-command --activate or --deactivate does not
work when used with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=686063
The configured calendar application might not actually be installed.
Instead of failing with an error message, hide the menu item altogether
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=686050
Since panel corners are currently square, this doesn't really affect much,
but it's very clear what the code was supposed to be. At the same time,
also fix up a redeclaration with 'let', which technically isnt' kosher.
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
If there are either no resident or persistent notifications, we'll
add some spacing for those boxes that may contain nothing. Make them
invisible to remove the spacing for those elements. It's possible
that we may want to be smarter about this in StBoxLayout to remove
spacing for zero-sized actors, but today is not the day.
https://bugzilla.gnome.org/show_bug.cgi?id=685919
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
Currently when the summary boxpointer is ungrabbed automatically
because the keyboard focus was moved outside the message tray
(for instance by selecting the overview search entry or opening
the right-click menu of a dash item), after the popup is hidden
_updateState() will grab focus and show the popup again.
Work around this by unsetting the clicked summary item when losing
focus to an actor outside the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=685156
Commit 448517032e added the message tray unconditionally to
the Ctrl-Alt-Tab popup, but while this makes sense for a normal
session, we do not want it in the login screen.
Be a bit more careful where we make the tray available.
https://bugzilla.gnome.org/show_bug.cgi?id=685914
