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
A missing extension directory isn't worth debug spew, so check
if the error when reading the extension directory is NOT_FOUND,
and if so, suppress output.
https://bugzilla.gnome.org/show_bug.cgi?id=685466
The preference controls whether the screen should be locked when
the screensaver is activated, not whether the screen should be
locked at all. In particular after having switched to a different
user, log out should not automatically switch back to the unlocked
session, so always activate the lock when user switching.
https://bugzilla.gnome.org/show_bug.cgi?id=685536
Currently Return is used to activate the default button of a modal
dialog if no key is specified. It makes sense to allow alternatives
as the keypad's Enter key as well in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=685511
Currently the default action is performed twice when pressing Return
in the login dialog, once in response to the entry's 'activate' signal,
and again by activating the default button. Usually this is not a
problem, as the second invocation is simply ignored, however it breaks
the case where multiple consecutive questions are asked (e.g. username
and password in the 'Not listed' case).
Fix the problem by not handling the 'activate' signal at all.
https://bugzilla.gnome.org/show_bug.cgi?id=685511
GDM does not allow concurrent logins of a single user, so making
'Switch Session' a user switch operation does not work - in order
to choose a different session, users have to log out.
Rather than making 'Switch Session' an alias of 'Log out' (which
is available anyway when multiple sessions are defined), remove
the item altogether - 'Switch Session' suggests an operation that
does not loose state, and we currently favor 'Switch Session' over
'Switch User', so on systems that have both multiple users and
multiple sessions, the latter would become unavailable.
https://bugzilla.gnome.org/show_bug.cgi?id=685062
Content-Type scanning can be super expensive. The autorun manager is meant
for local filesystems that are plugged into a USB port or similar, not
remote NFS or sshfs mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=684093
When Florian landed the new dash container to show the all apps button
always, he got the math wrong -- he forgot to add padding around the
container, and used the height of the box to calculate a y2 position,
rather than the y2 position of the box.
https://bugzilla.gnome.org/show_bug.cgi?id=684619
Currently the visibility of input volume is only updated when a stream
is added/removed - apparently no one noticed until now, as in the normal
user session we get away with this as long as we have some startup sound,
but this is not the case in the lock screen, so we may end up showing
input volume incorrectly.
https://bugzilla.gnome.org/show_bug.cgi?id=684611
The keyboard is shown/hidden automatically when (un)focusing a
ClutterText actor. This behavior is unwanted when opening the
extended keys popup, so focus changes to the popup are ignored.
However, we also want to ignore focus changes from the popup
to avoid the keyboard hiding itself after pressing an extended
key.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
The keyboard is shown/hidden automatically when (un)focusing a
ClutterText actor. This behavior breaks with the message tray now
grabbing/releasing key focus when toggled. Fix this by ignoring
all focus changes to or from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
Currently if a summary item signals that it has handled a click
itself, the tray hides itself. This behavior is wrong for the
On-Screen-Keyboard, which appears as a unit with the tray, so add
a property to opt-out of the default behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
GrabHelper automatically releases grabs when the user clicks outside
the grabbed actors. However at least for the message-tray (which is
the only user of grabHelper at the moment), we must ignore any events
from the On-Screen-Keyboard, to prevent the tray from hiding at every
key press.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
This fixes a case of _updateState() being called recursively,
resulting in stray grab()/ungrab() calls the leave the entire
desktop in a stuck focus state.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
The message tray is now modal and pushes the view up, but the keyboard
is shown below it. Solve this by applying a special styling to the
keyboard and message tray combination, and by not pushing the windows
up when the keyboard is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
When changing the user's avatar image, AccountsService will
overwrite the old image with the new one, so the location
returned by get_icon_file() is always the same.
In order to pick up the change, we need to make sure to clear the
previous image from both StTextureCache and StThemeNode's paint
cache.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
With the recent session mode changes, the visibility of settings
items is now only set on sessionMode::updated - while the signal
is emitted when the session mode is initialized, settings items
that are added after that are visible regardless of the allowSettings
setting until the next sessionMode::updated signal is received.
Fix this by explicitly setting the initial visibility of settings
items.
https://bugzilla.gnome.org/show_bug.cgi?id=684473
While the unlock dialog is created early so that it appears below
the shield while the curtain slides up, it is destroyed immediately
when the shield slides back in.
Keep it around until the shield is down instead.
https://bugzilla.gnome.org/show_bug.cgi?id=684342
When locking the screen, the user menu is moved to the opposite
side. Unless we close the menu immediately without animation, the
menu will jump to the other side and fade out while the screen
shield slides down.
https://bugzilla.gnome.org/show_bug.cgi?id=684343
Instead of leaving the login or unlock dialogs in an inconsistent state,
catch DBus errors and show an Authentication Error message. The error
details are logged in the session logs.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
Due to the way the IBus API works we might get property changes while
the menu is already open. In that case the separator visibility logic
doesn't work since it only applies on menu open/close. This works
around that issue.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
IBus has a properties API which are basically generic knobs into the
engine which are serialized and presented in a way that allows us to
easily build actionable UI elements with them.
Instead of implementing the whole generic system and accepting
everything coming out of the engines, for now, this patch just adds
support for a couple of important IBus Anthy properties.
https://bugzilla.gnome.org/show_bug.cgi?id=682314
The screenshield requires gdm 3.5, which can be problematic in
jhbuild configurations, or distributions that don't use GDM as the display
manager. Allow transparent fallback to gnome-screensaver in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683060
When the tray is triggered by keybinding rather than dwelling, the
first summary item should be given key focus. Currently this is
achieved by grabbing the focus before toggling the tray, so that
the grabHelper will move the focus for us. However this interferes
with the grabHelper's focus save/restore mechanism - for instance,
after using the keybinding once, the tray will always come up with
the first item focused.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently it is only possible to use keynav inside the tray if it
has been triggered with the keyboard shortcut. Make it possible to
initiate keynav by hitting Tab in other cases as well.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently opening the summary boxpointer acts as a stop gap for
keynav - the only shortcut still working is "Escape" to hide the
tray altogether.
Change the handling of Escape to only close the summary boxpointer
and allow to use the down arrow as alternative (unless the boxpointer
already processes the key press itself of course, like the chat
entry does). Also add a Delete shortcut to dismiss the open summary
item.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently clicks outside the grabbed actors are handled the same as
the user pressing Escape - a single actor is popped from the grab stack.
However according to the design, outside clicks should release all grabs.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
When using keynav in the top bar, menus may be opened using the
down arrow; in a similar fashion, allow to open the summary
boxpointer with the up arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
Currently the HistoryManager consumes all arrow up/down key presses
unconditionally. Change this to only consume the event if the entry
text was actually changed, e.g. not when trying to move past the
first/last item.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
'destroy' is emitted before the actor is unmapped during destruction, so
notify::mapped would emit an exception. Since unmapping is guaranteed,
the 'destroy' signal is unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=684154
Remove the PlacesManager, its search provider and all associated code.
Places search is now provided by nautilus using the external search
provider API.
https://bugzilla.gnome.org/show_bug.cgi?id=683506
When Dan Winship wrote the GrabHelper code originally, it didn't
handle a grab stack. I wrote the grab stack code hastily when landed
the message tray, not understanding all of the code that was involved
here.
Fix it so that we properly do the operations for each type of grab
when we first need to, and not sometimes when the first grab is taken.
https://bugzilla.gnome.org/show_bug.cgi?id=683546
_hideTray() is called by _updateState() when the tray is visible
but should be hidden; however, _updateState() may be called again
from within _hideTray() when releasing the GrabHelper grab, so
unless we update the _trayState variable before that, _hideTray()
will be called a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=682243
A couple of people have walked up to me and asked how to get to the
unlock screen from the screen shield. This was partly addressed by
bug 682285, but all three people who asked me about this said they
tried the return key and were surprised when it didn't work.
It sort of makes sense, since the user is "enter"ing the computer or
"return"ing to it.
This commit makes enter work in addition to the existing escape key.
https://bugzilla.gnome.org/show_bug.cgi?id=683889
Since we now use the capture phase to feed events into the input
method, we must set the capture flag for the event that starts
searches so that IMs can get at it.
https://bugzilla.gnome.org/show_bug.cgi?id=684040
If the user starts typing right away, assume that the entry is
for a password and don't clear it when the secret request actually
comes. Then, if the user completes typing, we also stash the answer
and send it to GDM right away on the first PAM prompt.
https://bugzilla.gnome.org/show_bug.cgi?id=681576
The onUngrab callback already checks if all notifications are destroyed and
hides immediately if so. Previous code instead would leave state handling
in an inconsistent state, by not removing the grab, not setting
summaryBoxPointerState to HIDDEN and not disconnecting various signals.
https://bugzilla.gnome.org/show_bug.cgi?id=684036
