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
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
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
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
This ensures that the desktop window's smooth fadeout when going to
the overview is in the same spot as the desktop window, which may not
always be at 0, 0.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
Having the tooltip change when it's visible looks strange and glitchy.
This also makes sure that "Remove from Favorites" doesn't change, even
when the user removes their mouse cursor from it.
https://bugzilla.gnome.org/show_bug.cgi?id=685313
_moveFocusToItems seems to be called to early causing
clutter_actor_grab_key_focus not to be called.
So queue another attempt with BEFORE_REDRAW priority when
this happens to make sure we actually move the focus sucessfully.
https://bugzilla.gnome.org/show_bug.cgi?id=684650
