If it is updated after checking, it counts the number of failures
not including the current one, so it allows one extra attempt. Instead,
by updating it before checking, we get the expected result of dropping the
curtain at the third password.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
When the user has the entered the password for the second time
and clicked OK, clear messages from the previous attempt, so any
new failure is shown clearly.
https://bugzilla.gnome.org/show_bug.cgi?id=687132
After some changes, the tooltip label at the dash is not available
until it is visually shown. As this is not anymore a reliable
source of accessible name, we just set the accessible name
with the string used on that label.
https://bugzilla.gnome.org/show_bug.cgi?id=686583
Instead of keeping track of the old adjustment.upper keep track of the
old adjustment.value that corresponded to the bottom scroll position.
This fixes the integrated chatview not always scrolling to the bottom
by removing the assumption that page_size is constant between updates,
which is not the case as the view is presented in various different ways.
https://bugzilla.gnome.org/show_bug.cgi?id=686571
I've heard quite a bit of feedback from people who want to log out,
even if they are the sole user on their system. It doesn't seem worth
alienating them over this; so add a setting to make the 'Log out' item
always show up.
https://bugzilla.gnome.org/show_bug.cgi?id=686057
The libedataserverui dependency is a relic of the old E-D-S API.
As of 3.6.0, E-D-S now centralizes authentication prompts so clients
don't have to display their own. This also allows trading the GTK+
main loop for a plain GMainLoop in gnome-shell-calendar-server.c.
https://bugzilla.gnome.org/show_bug.cgi?id=687189
(cherry picked from commit 29714922ea)
Rationale:
- Getting something out of the way should be quick;
- Very few things in the real world move linearly so, linear
animations, especially for something as big and visible as this,
felt too artificial;
- Moving the curtain out should start slower to make it feel like
having weight (it fills the whole screen after all) but quickly
accelerate towards the end to make it snappy too.
https://bugzilla.gnome.org/show_bug.cgi?id=686745
Currently close() is a no-op when the menu has already been closed.
However, repeated calls could pass different animation parameters.
For instance in the user menu, we try to hide the menu immediately
before locking the screen, to avoid the popup jumping across the
screen while fading out - as we do this from the corresponding
item's activate handler, the closing is still animated if the menu's
own handler (which requests a full animation) is run first.
Fix this by changing close() to overwrite ongoing animations before
bailing out early.
https://bugzilla.gnome.org/show_bug.cgi?id=686484
As the messages start with a string placeholder that might be
untranslated, we need an explicit mark to ensure that the string
does not end up as LTR.
https://bugzilla.gnome.org/show_bug.cgi?id=686630
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
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
