Filtering out "non-interesting" windows beforehand as we currently do
means that we may get properties that should be based on all windows,
like the last time the application was used, wrong.
Just track all windows and filter out non-interesting windows manually
in the one place we actually care about the difference.
https://bugzilla.gnome.org/show_bug.cgi?id=719824
For mysterious reasons I'm not sure of myself, navigate_focus will only focus
mapped actors. So, make sure the widget is showing before navigating to it.
https://bugzilla.gnome.org/show_bug.cgi?id=709853
After a user types in their password at the login screen, one
of two things can happen
1) a new session is started
2) an existing session is switched to
In the latter case, GDM sends a reset signal to the login screen,
so it knows to go back to the user list and wait to be summoned
again.
Unfortunately, all reset signals are ignored after verification
success. The reason is because the reset handler was copied from
the unlock dialog as part of a deduplication effort in commit
7e7295f259 and the unlock dialog
handler at the time also emitted a "failed" signal on reset
(which wouldn't make sense to emit after success).
These days "failed" is handled in a different way.
This commit changes the code to let reset signals through after
successful verification.
https://bugzilla.gnome.org/show_bug.cgi?id=710456
The methods we call in _updateState may not be reentrant, so make
sure that we never get into a situation where _updateState, through
some crazy chain of events, calls itself.
https://bugzilla.gnome.org/show_bug.cgi?id=711694
We currently only ensure that width and height are positive, so it
is still possible to pass in values that don't make any sense at all
(which may even result in a crash when exceeding limits imposed by
X11).
There is nothing to screenshot outside the actual screen area, so
restrict the parameters to that.
https://bugzilla.gnome.org/show_bug.cgi?id=699752
The org.gnome.login-screen schema contains a key to disable the
power/restart buttons; our support for this fell victim to the
new combined status menu, add it back.
https://bugzilla.gnome.org/show_bug.cgi?id=711244
The application picker will always open with the view that was last
selected during the session, but the selection is reset on each
restart. This results in some annoyance for users that use the
ALL view exclusively, as they have to toggle views once each
session - the same would apply to exclusive FREQUENT view users
were the defaults to be changed, so the best solution is to simply
make the selected view persistent by storing it in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=710042
If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
oVirt is software for managing medium-to-large scale deployments of
virtual machine guests across multiple hosts. It supports a feature
where users can authenticate with a central server and get
transparently connected to a guest system and then automatically get logged
into that guest to an associated user session.
Guests using old versions of GDM support this single-sign-on capability
by means of a greeter plugin, using the old greeter's extension
API.
This commit adds similar support to the gnome-shell based login screen.
How it works:
* The OVirtCredentialsManager singleton listens for
'org.ovirt.vdsm.Credentials.UserAuthenticated'
D-Bus signal on the system bus from the
'org.ovirt.vdsm.Credentials'
bus name. The service that provides that bus name is called
the oVirt guest agent. It is also responsible for interacting
with the the central server to get user credentials.
* This UserAuthenticated signal passes, as a parameter, the a token
which needs to be passed through to the PAM service that is specifically
set up to integrate with the oVirt authentication architecture.
The singleton object keeps the token internally so it can be queried
later on.
* The OVirtCredentialsManager emits a signal 'user-authenticated' on
it's object once the dbus signal is triggered
* When the 'user-authenticated' signal is emitted, the login screen
tells GDM to start user verification using the PAM service. The
authentication stack of the service includes a PAM module
provided by oVirt that securely retrieves user credentials
from the oVirt guest agent. The PAM module then forwards those
credentials on to other modules in the stack so, e.g.,
the user's gnome keyring can be automatically unlocked.
* In case of the screen shield being visible, it also will react on that
'user-authenticated' signal and lift the shield.
In that case the login screen will check on construction time if
the signal has already been triggered, and a token is available.
If a token is available it will immediately trigger the functionality
as described above.
Signed-off-by: Vinzenz Feenstra <evilissimo@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=702162
