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
St.Theme.load_stylesheet() does not queue a theme context change, so
any styling of widgets created before will not be updated. To fix this,
load the stylesheet before the extension builds its own UI in enable()
https://bugzilla.gnome.org/show_bug.cgi?id=682128
This means that right-clicking on an entry shouldn't visibly change the theme,
which is unexpected. Make sure that closing the menu refocused the entry, too.
https://bugzilla.gnome.org/show_bug.cgi?id=683509
When the dash contains more icons than fit at the minimum icon size,
icons are cut off at the end. This means that the show-apps button
will be the first to disappear, which is problematic given it's the
sole access point for other applications (for those that refuse to
use search at least).
Fix by using a dedicated widget for the dash actor, so that in case
of underallocation only icons above the show-apps button end up being
cut off.
https://bugzilla.gnome.org/show_bug.cgi?id=683340
Have distinct session modes for the lock screen and the unlock dialog,
and rework the logic in ScreenShield to have the lock-screen mode stack
onto the unlock-dialog mode (where applicable)
https://bugzilla.gnome.org/show_bug.cgi?id=682542
They are bigger and show an ellipsis if the count goes over 99. They
now have a blurred background and a drop shadow based on
data/theme/close-window.svg.
https://bugzilla.gnome.org/show_bug.cgi?id=682891
ClutterBinLayout is so amazingly broken: it uses the y_expand property to
find out if the children needs to honor alignment/fill, but that property is
"bubbled up" from the grand-children, so the notificationWidget would notice
the y_expand on the notificationBin (necessary to make the layout manager on
notificationWidget honor the alignment property for the bin), and would
receive the full height of the MessageTray actor from the parent's layout manager,
resulting in a notificationWidget shifting up, with the notification detached
from the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683628
The stage's background color can visible on screencasts when multiple monitors
with different resolutions are in use.
Change it to from blue to grey to look better as requested by the designers.
https://bugzilla.gnome.org/show_bug.cgi?id=683514
If the arrow's origin is so close to the edge that the arrow will not
be isosceles, we try to compensate as follows:
- We skip the rounded corner and settle for a right angled arrow as
as shown below.
|\_____
|
|
- If the arrow was going to be acute angled, we move the position of
the box to maintain the arrow's accuracy.
https://bugzilla.gnome.org/show_bug.cgi?id=680077
With the recent session mode changes, there is now a mix of modes
that are meant to apply to the entire session (specified as parameter
to the --mode command line switch) and temporary modes like the lock
screen; introduce a property to make the difference explicit, and only
allow "primary" modes to be specified on the command line.
https://bugzilla.gnome.org/show_bug.cgi?id=683488
Users of GrabHelper.grab() espect that the actor parameter (or one of its
children) will receive focus, irrespective of the previous focus location.
This fixes the key focus on the chat entry when expanding the notification.
https://bugzilla.gnome.org/show_bug.cgi?id=683449
Hidden children are currently ignored in width requests; in the
case of submenu items, this results in abrupt width changes of
open menus when the corresponding SubMenuMenuItem is toggled.
To fix, only ignore SubMenu children when the corresponding
SubMenuMenuItem is hidden as well.
https://bugzilla.gnome.org/show_bug.cgi?id=683485
The special padding rules for submenu items currently ensure that
content aligns properly when the scrollbar is shown. While they
work nicely for the network menu, it looks odd for non-scrolled
submenus, so make this case explicit by introducing a :scrolled
pseudo class and adjust the style rules to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=683009
The code here was trying to center the label, but that didn't
happen because we allocated the entire space to the label, which
still plonks it at the top.
Message tray sources cannot be reused after destruction, so connect
to 'destroy' signal and clear out the previous one.
Also, fix some code paths that used the autorun manager incorrectly.
https://bugzilla.gnome.org/show_bug.cgi?id=683377
Previous code was activating the networkAgent and telepathyClient
in the lock-screen, irrespective of the previous mode.
Now it checks if the session mode is locked down, and if so it refuses
to start new components.
https://bugzilla.gnome.org/show_bug.cgi?id=683400
Previous code had a mixture of fixed positioning and ClutterBinLayout,
and this was broken badly for autorun notifications.
Rewrite to use ClutterBinLayout and Clutter properties exclusively.
https://bugzilla.gnome.org/show_bug.cgi?id=683378
Panel already forces each item to be a PanelMenu.Button, so it's better
to have the latter handle the bin container too, instead of attaching
a private property that might collide with internal usage by the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Previously we would only read the default sink and default source when
the connection to PulseAudio succeded. This worked because all VolumeMenu
users where initialized synchronously during shell load.
With the recent session mode changes though, the lock screen menu is
created on demand, and when it loads PA is already connected, so
it doesn't update the sliders.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Have main.js call .showDialog() when going back from the lock-screen, instead
of using the return value of createUnlockDialog to know if the dialog
was persistent.
_keepDialog is still used as LoginDialog cannot really be destroyed,
and cancelling it does not destroy it.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
The sudden transition from the lock screen to the user session
may be a bit sudden and overwhelming. Make ourselves more shell-like
by resizing out the screen shield according to mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=683170
It makes more sense to define session modes in terms of what you're
adding to the bare shell, not in terms of what you're taking away
from the user session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
If we don't freeze the presence icon, we can end up in a place where
we'll be updating the icon before we fade out the panel indicators when
coming back from the lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Components are pieces of the shell code that can be added/removed
at runtime, like extension, but are tied more directly to a session
mode. The session polkit agent, the network agent, autorun/automount,
are all components, keyring, recorder and telepathy client are all
now copmonents.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Since we eventually want to add a system for changing the top panel
contents depending on the current state of the shell, let's use the
"session mode" feature for this, and add a mechanism for updating the
session mode at runtime. Add support for every key besides the two
functional keys, and make all the components update automatically when the
session mode is changed. Add a new lock-screen mode, and make the lock
screen change to this when locked.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Instead of showing a notification, add a small message immediately
below the entry, and give the user two more attempts to login,
before going back to the welcome or lock screen.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
The supposed reason for launching the calendar server in a peculiar
way was so that the process would be killed when the Shell was killed,
but that didn't actually work. Launch the calendar server through auto-start,
and persist all throughout the session.
https://bugzilla.gnome.org/show_bug.cgi?id=683156
Commit 5c6b1fd0c modified the hierarchy of SummaryItem contents, by
introducing a notificationStackWidget in place of the StackView, but
forgot to update the bits in ScreenShield.NotificationsBox that accessed
and reparented that directly, causing a crash by invalid theme node access.
https://bugzilla.gnome.org/show_bug.cgi?id=682683
We already could build the right part of the panel declaratively according
to the session mode. Extend that to handle the left and center parts.
Also, move the mapping from the roles to the classes in panel.js, as it shared
by all modes.
https://bugzilla.gnome.org/show_bug.cgi?id=682546
Ensure that all async callbacks check and ignore G_IO_ERROR_CANCELLED.
Ensure that all runs of authentication have their own GCancellable, so
that .begin() can be called multiple times on the same user verifier.
Check for fingerprint reader when beginning authentication, and not
when reset by GDM.
https://bugzilla.gnome.org/show_bug.cgi?id=682544
Introduce a StShadowHelper to manage drop shadows from JS (which
cannot use Cogl directly), and use it in a new StWidget-derived
JS class to draw the arrow.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
User testing has shown that it is not discoverable that the whole
lock screen can be dragged. A new mockup includes more arrows
and a short animation every 4 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=682285
Legacy tray icons may want to take a pointer grab to show a popup menu,
and this is incompatible with message tray modality. To solve this,
escape the tray when forwarding clicks to the tray icons, and wait
for the input mode change to actually synthetize the X event.
https://bugzilla.gnome.org/show_bug.cgi?id=682244
This makes sense if we want to follow what the following comment says:
// We also want to keep it onscreen, and separated from the
// edge by the same distance as the main part of the box is
// separated from its sourceActor
Using a magic number violates the "separated from the edge ...
separated from its sourceActor" part.
https://bugzilla.gnome.org/show_bug.cgi?id=682343
Each summary icon is 48x48 with a padding of 6px on each side. Thus,
each summary item is 60px wide. Therefore the summary mode should be
60px high instead of 72px.
Changed the tray actor to use a ClutterBinLayout so that it honors the
y-expand property of its children.
https://bugzilla.gnome.org/show_bug.cgi?id=682248
Previously, when toggling a switch on we tried to replicate NM policy and
find a good connection to activate. This is broken in many situations.
Instead, only activate something when we can be sure it's what the user
wants (i.e. when there is only one connection, or when there is none,
and thus connecting will trigger the config dialog)
https://bugzilla.gnome.org/show_bug.cgi?id=683136
In multi-monitor setups, the screen might extend below the edge of
the monitor that holds the tray. In that case the tray is currently
triggered from a secondary monitor, which is rather surprising;
change the check to use the correct monitor geometry instead.
https://bugzilla.gnome.org/show_bug.cgi?id=683044
PopupMenuBase relies on open-state-changed to update the separator
visibility, but PopupMenuSection were only emitting when the parent
closed, so the first time the menu was opened, separator visiblity was
wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=682998
The design has a combined volume-network-power indicator in the lock
screen, which when opened shows a volume slider. Implement it by abstracting
the volume menu into a PopupMenuSection, and by creating three StIcons
bound to the real ones.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
The height of an unexpanded notification could include expanded
content if the notification has extra widgets (like actions and images),
so tweening to that cause it to expand visually.
Instead, use the height of the message tray before the restyle
as an upper bound.
https://bugzilla.gnome.org/show_bug.cgi?id=682738
Commit 22eea750 made info messages show up in the lock screen, but
as setShowWhenLocked() throws an exception when called on non-transient
notifications, the transient hint has to be set first.
https://bugzilla.gnome.org/show_bug.cgi?id=682268
Bumping overrides any animation, and causes the installed onComplete
not to run, which in turn breaks suspending from the user menu (as
it listens to lock-screen-shown).
Add a state variable (using an enumeration shared with messageTray)
to control the lock screen, and only bump when the lock is still.
https://bugzilla.gnome.org/show_bug.cgi?id=682746
Showing the removable devices is potentially a security risk (as
they include network shares). Also, a nautilus launched from there
can't be used, so it's just a way to overload the system.
https://bugzilla.gnome.org/show_bug.cgi?id=681143
This makes the workspace indicator respect the "padding" style attribute.
Also, since we no longer draw the border on top of the thumbnail,
we need to be pixel-precise in allocating the indicator height.
We use this to make the workspace selector more similar to the mockup.
https://bugzilla.gnome.org/show_bug.cgi?id=662087
If the user has the mouse down - for example when they are selecting
text and dragging - then the attempt to get a modal grab will fail.
grabHelper: allow the .grab() function to fail and do nothing in this
modal case if the grab fails.
messageTray: handle grab failure and don't pop up the tray. Change the
logic for tray dwelling so that we only try to pop up the tray once
while the pointer is in the dwell area - this avoids the possiility
that the tray will pop up once the user releases the mouse.
https://bugzilla.gnome.org/show_bug.cgi?id=682385
Currently we load all search providers from XDG_DATA_DIRS, so if
the same provider is installed several times in different directories,
we happily show duplicate results. To fix, keep track of all remote
providers we add and skip those that already have been loaded from a
different directory.
https://bugzilla.gnome.org/show_bug.cgi?id=682470
The app menu is hidden when entering the lock screen, however it
might be shown again while the lock is still in place - we don't
want this ever to be the case, so make show() a no-op while the
screen is locked.
https://bugzilla.gnome.org/show_bug.cgi?id=682475
AutorunManager relied on AutomountManager to find if the session
was active, and this broke when this stopped exporting a public
method for it. Fix AutorunManager to have its own reference to
the LoginManager.
https://bugzilla.gnome.org/show_bug.cgi?id=682455
Currently we animate scrolling to the active workspace both when
the number of workspaces changed and after changing the active
workspace. So in case we don't actually change workspace, this
results in an unnecessary animation that may even have unwanted
side effects: when done during the overview transition (e.g. in
the case of opening and activating a window on an empty workspace),
non-active workspaces become visible during the transition.
To fix, don't scroll to the active workspace when the number of
workspaces changes and rely on the 'switch-workspace' signal being
emitted as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=682002
Since dwell at the bottom of the screen is now the primary way of
summoning the tray, removing the hot corner to avoid having two
separate things that can be accidentally triggered.
https://bugzilla.gnome.org/show_bug.cgi?id=682310
Don't log a warning if an unrecognized device type is seen.
Don't show slave connections in the menu. (Eg, don't show the
individual wired connections making up a bond, since they can't be
used individually.)
Make the icon only reflect the status of connections that are visible
in the menu. (ie, don't show the "connecting" icon when an
unrecognized connection type is connecting, and don't show a
"connected" status if the only active connections are of unrecognized
types.)
https://bugzilla.gnome.org/show_bug.cgi?id=682364
