When we implemented the new designs, we lost the ability to suspend
from the system menu. Re-enable this ability by re-adding the hidden
"Alt" shortcut item.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
We show a lightbox when we suspend, to animate the fading to black
caused by turning off the monitors, but we need to hide it when
coming back, otherwise the user is just staring at a black screen
it until he moves the mouse or presses a key.
https://bugzilla.gnome.org/show_bug.cgi?id=706654
Sometimes gnome-session hands us a bad object path for JIT inhibitors
it creates for XSMP clients. While this is a bug in gnome-session, we
shouldn't show an empty-looking dialog here.
https://bugzilla.gnome.org/show_bug.cgi?id=706612
When locking manually (or locking with an animation), fade the
screen to black after a small timeout. This provides a smoother
experience, instead of abruptly turning off the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=699112
Unfortunately, display configuration can and does fail, due
to unspecified HW constraints, drivers bugs, unsupported exotic
configurations or just bad luck.
So when the user makes a change in the control center, show
a dialog asking him if it looks OK, and revert back after 20 seconds
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=706208
All our modal dialogs are given a fixed width and grow vertically
as necessary. Set the request mode accordingly, so that wrapped
labels are considered correctly during size request, and not only
at allocation time (where they'll either take away from the padding
or even cause the dialog to overflow).
https://bugzilla.gnome.org/show_bug.cgi?id=704015
The only point of using a custom container here was to prevent StBoxLayout
from enforcing the wrong request mode based on the orientation. With that
issue fixed, we can simplify the checkbox widget significantly.
https://bugzilla.gnome.org/show_bug.cgi?id=703811
Replace more direct XFixes usage with a the appropriate abstraction
API from mutter, which is guaranteed to work in wayland too.
It doesn't yet replace pointer position tracking, although probably
it should.
Also, because now we're using Mutter API, we lose the standalone
test case.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Mutter now includes an object with the same purpose and functionality
as ShellXFixesCursor, so we can replace our XFixes code with it
and work under wayland too.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Triangles should be flipped in RTL. This is the easiest way to do it that
doesn't rely on modifying the rotating logic, though it is a bit hacky since
the ClutterActor "scale-x" property technically considers the lower bound
to be 0. It works, though.
GrabHelpers use a 'captured-event' to steal events and emulate
modality or grab-like semantics. There can be issues when you try to
use multiple GrabHelpers stacked on each other. As Clutter follows
the DOM-like semantics of "first come, first serve", when a second
GrabHelper connects to 'captured-event', its callback will only be
processed *after* the first GrabHelper's callback is called.
This breaks the expectation of narrowing modality where new modals
take priority over the old ones.
Solving this globally in a cleaner manner would require a rewrite of
pushModal/GrabHelper. As a stopgap fix for now, use one shared
'captured-event' handler between all GrabHelper instances, and
delegate to the individual GrabHelpers.
https://bugzilla.gnome.org/show_bug.cgi?id=699272
This commit detects when a user inserts a smartcard,
and then initiates user verification using the gdm-smartcard
PAM service.
Likewise, if a user removes their smartcard, password verification
(or the user list depending on auth mode and configuration) are initiated
https://bugzilla.gnome.org/show_bug.cgi?id=683437
This commit introduces a new BeginRequestType enum which gets
passed to the 'reset' signal to specify whether
a username should be provided to the begin() method and changes
the loginDialog to comply.
Currently, the signal only ever gets emitted with
AuthPrompt.BeginRequestType.PROVIDE_USERNAME
but that will change in the future when providing smartcard
support.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
We currently emit "failed" any time the UserVerifier is reset,
and user verification didn't succeed prior.
A more conceptually clear time to emit "failed" would be if
the UserVerifier is reset and user verification failed prior,
and to emit "failed" if the user cancels unlock.
This commit restructures things to do that. Aside from being
more conceptually clear, it also lays the groundwork for us
to be able to reset the unlock screen without failing.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
If we don't have a connection at startup or we transition from
having a connection to not having a connection, we need to make
sure we hide the correct indicators.
