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
authPrompt.reset() currently only leaves the authPrompt in a
sane state if the user isn't verifying.
This commit makes sure to cancel verification if a reset happens
while verification is in process.
https://bugzilla.gnome.org/show_bug.cgi?id=683437
In the new application model, there is one ID shared by GApplication,
DBus and .desktop files, so we can use that for the association,
instead of fiddling with badly cased wm classes.
https://bugzilla.gnome.org/show_bug.cgi?id=706252
This is needed to handle applications that are converted to
reverse dns notation, if their application ID includes capital
letters (as it is often the case for DBus names)
https://bugzilla.gnome.org/show_bug.cgi?id=706252
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.
_updateState has a lot of variables that sort of gunk up the
code and make it more unreadable than need be. Clean up the logic
a lot by moving those variables into the places that they actually
matter, renaming them to remove prefixes, and remove some conditions
that are always met.
Right now the code chooses to animate based on whether or not the
notification was "removed", which is quite a sketchy subject. For
now, add an additional case so that we don't animate when we transition
to the lock screen.
Adds 15px padding to all sides of provider icon to have padding
which seems equal to that of list-search-result-content. This aligns the
provider icon vertically with the search result content.
Padding is set to 15px as list-search-result-content has 12px padding
and the outer box (list-search-result) has 3px.
http://bugzilla.gnome.org/show_bug.cgi?id=695760
When the triangle rotates (when sub-menu is expanded), it seems as if
the triangle pivots from one corner even though rotation center is set
to Clutter.Gravity.CENTER. Hence the rotation center is set nearer to
the edge than to the corner ([0.3, 0.5] instead of [0.5, 0.5]) so that
it doesn't appear odd.
Also pivot_point is used instead of rotation_center_z_gravity as it is
deprecated.
http://bugzilla.gnome.org/show_bug.cgi?id=703109
This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
The existing app menu was a kludge of legacy code that tried to manage
a bunch of state, and had a number of issues:
* It didn't properly manage visibility when combined with multiple
apps and the overview.
* It didn't properly manage reactivity when tabbing away from a busy
app to another app.
* It didn't properly disconnect signals when going from one app
to nothing.
and countless others. Rewrite it to use the new "sync" code pattern,
where we centralize all state management and do transitions from that,
rather than strange and quirky control flow.
https://bugzilla.gnome.org/show_bug.cgi?id=705898
Make the lock dialog group reactive, to intercept any events
before they go to the actors below.
In the future, we may restructure our chrome to have a clear
layer system, but for now it fixes a security issue in the lock
screen (you can see the contents of the windows by dragging
if the screen was locked with the overview active)
https://bugzilla.gnome.org/show_bug.cgi?id=705840
