Currently the entry takes the intial key focus, but is not actually
part of the focus chain. Fix that, even though keynav does not work
too well for the dialog anyway, due to the entry consuming tab for
command completion.
https://bugzilla.gnome.org/show_bug.cgi?id=687127
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
Reposition the window overlay when the title changes, using the current
transformed size of the window clone.
Includes a test that changes title to a string of random length every 3 seconds.
Based on a patch by Alex Hultman <alexhultman@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=620874
While looking at how the plymouth implementation was built, I was so
short-sighted and focused on the string "_XROOTPMAP_ID" that I didn't
realize it was the name of the standard background on the root window.
Remove our own implementation, and switch to using a standard mutter
MetaBackgroundActor.
https://bugzilla.gnome.org/show_bug.cgi?id=682428
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
When the summary notification is open when the tray is closed, we end
up with two concurrent animations: the notification fading out, and the
tray moving away from underneath it. Sliding out the tray should be the
primary transition here, so hide the notification immediately to not
draw the user's attention away from it.
https://bugzilla.gnome.org/show_bug.cgi?id=686888
Having the close button move away from under the pointer after
clicking it is confusing and distracts from the main transition,
which is hiding the notification. Just hide it immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=682237
Rather than destroying the entire source, which is unintuitive, simply
close the notification. Removing the entire source is still possible
by right-clicking on the summary item and choosing "Remove".
https://bugzilla.gnome.org/show_bug.cgi?id=682237
GDM has a 'logo' key in its schema to allow distributors to add
some branding. It is currently placed above the user list, which
no longer works too well since the login screen lost its dialog
window. Display the logo in the top-left corner instead of the
Activities button instead.
https://bugzilla.gnome.org/show_bug.cgi?id=685852
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
Change the layout strategy to be more like the mockups. With less than
two rows of windows, we try to fit every window in a non-aligned situation;
with more than three rows of windows, we try to fit every window in an
aligned situation.
Based heavily on a patch from Pierre-Eric Pelloux-Prayer <pelloux@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=582650
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
Hide workspace switcher if dynamic workspaces is disabled and number of
workspaces is set to one only, since the user is bound to only one workspace
and showing the switcher is redundant.
Signed-off-by: Seif Lotfy <seif@lotfy.com>
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
Due to a typo, it never worked correctly. After a fix-up to the appropriate
method, the behavior is suboptimal, as the buttons only fade in the first time
the modal dialog is constructed. Just remove the fade-in behavior, rather than
keeping this non-working code around.
https://bugzilla.gnome.org/show_bug.cgi?id=677426
This is a workaround for power users for the "Show Apps" button
placement being too inconvenient to press at the bottom of the
dash favorites list.
Unity also uses Super+A to show the Apps lens.
https://bugzilla.gnome.org/show_bug.cgi?id=685738
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.
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
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
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
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
'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
Look at the focus window's interaction timestamp to catch the case
where the user is typing and knocks the pointer into the tray or
mouses down to the bottom of the screen and clicks on something.
If the focus window's interaction time differs at the start and
end of the tray dwell then we don't activate the tray.
https://bugzilla.gnome.org/show_bug.cgi?id=683811
In gdm, we would attempt to become modal during the synchronous initialization,
and this would fail, as X prevents grabs on unmapped windows. Instead,
wait for the stage to be visible before becoming modal.
https://bugzilla.gnome.org/show_bug.cgi?id=683357
As PAM messages are now shown below the password entry, there is no
need for this complexity, and we can just hide all notifications.
Also, this avoids the ambiguity between notification.showWhenLocked and
source.showInLockScreen, which have very different effects.
https://bugzilla.gnome.org/show_bug.cgi?id=683369
The selector for insensitive popup menu items was wrong (a PopupMenuItem is
a ShellGenericContainer, not a StButton). Fixing it showed that previous
:insensitive tracking was manual for a reason: we have many items that are
not reactive, but don't want the insensitive styling (for example those in
the battery menu).
Fix it by adding a new style-class, popup-inactive-menu-item, that is added
to all new PopupMenuItems that are not activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=683988
CLUTTER_CURRENT_TIME (like GDK_CURRENT_TIME and libX11 CurrentTime) is 0,
and thus compares lower than all valid timestamps, meaning that
focus changes without an X11 event in the stack are ignored by
the on screen keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=664309
pending-messages-removed is emitted for sent messages too, but we don't
include those in the _pendingMessages list. Avoid useless spew in the session
logs in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
