Use the new Hash.Map class, and store signal connections along with
the source and summaryItem. This allows to remove sources without destroying
them.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
During the box pointer animation, other events can trigger an updateState,
losing the information that the summary is hiding and thus never disconnecting
the signals. Then, this stale connections can cause stacktraces, as they
fire when summaryBoxPointerItem is null.
https://bugzilla.gnome.org/show_bug.cgi?id=692693
Hiding notificationWidget with a telepathy notification causes
unfocused to be emitted, which causes a reentrant updateState.
If another notification is queued, it is shown before the old
one is cleared.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
These were lost when we moved away with StIconType. The idea was that
apps needed to include -symbolic in their action IDs, but apps were
not updated, and it never makes sense to have non symbolic icons there,
so let's restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
This fixes the image and scrollbars peeking through in banner mode,
because StTable wasn't able to allocate them at the restricted height
imposed by CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=692091
Switching style on Overview::hiding creates a weird effect, as the noise
texture is shown while the overview is still visibile. Instead, wait for
the tray to be fully hidden, then apply the new style.
As now the switch is invisible, there is no need for the transition
(which introduced the same problem on overview showing)
https://bugzilla.gnome.org/show_bug.cgi?id=689091
If the chosen action is not open, the tray should not be closed, to
let the user further interact with it (for example to mute or remove
more sources)
https://bugzilla.gnome.org/show_bug.cgi?id=689296
MessageTray._tween sets the state variable to the in-progress value,
so it must be sure that at the end of the animation the value will
be the corresponding final and nothing else will happen in between.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
Turns out that tweener has a very complex logic to decide when a new
tween on the same properties overrides completely the old, and unfortunately
what we were doing was not enough in all cases.
Just be explicit, and don't let anything else mess with the state.
https://bugzilla.gnome.org/show_bug.cgi?id=688895
Open a modal dialog, try to open the message tray -> no effect, the message
tray is blocked by the dialog.
Close the dialog, try to open the message tray by pointer -> still
no effect, because the old timeout id was not cleared the first time,
so the dwell callback thinks the tray is about to open.
https://bugzilla.gnome.org/show_bug.cgi?id=688750
The top panel and message tray icons were by default a gnome foot and
are replaced by better ones. The applications icon is now using the
symbolic apps icon of the dash, and the windows icon is also improved.
https://bugzilla.gnome.org/show_bug.cgi?id=641303
MessageTray tweens both opacity and y to hide or show _notificationWidget,
but only y when expanding it. This means that an existing tween to hide
the notification will continue running, clearing the notification state.
If the hiding one completes before the showing one, the onComplete handler
will throw an exception (because the notification was nullified) and
therefore break the state tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=683986
For now we just use it to assign an identifier to modal modes in
which we want to allow some keybindings, but we don't use it for
any actual filtering; we'll start doing this shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
At the moment, only the mouse can be used to focus and answer a chat
notification.
This adds a new keybinding (defaults to <Super>+n) to focus and expand
the active notification.
https://bugzilla.gnome.org/show_bug.cgi?id=652082
Notifications that are created in response to direct user actions like
"is ready" or "'foo' has been removed from favorites" should always be
displayed even though the user has marked him/herself busy.
https://bugzilla.gnome.org/show_bug.cgi?id=662900
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
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
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
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 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
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
_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
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
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
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
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
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
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
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
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
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
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
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
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
If the user leaves the mouse pointer at the bottom of the screen for a second,
open the tray. This simulates the eventual plan of measuring "pressure" by how
far the pointer is moved past the edge of the screen. Measuring pressure will
take X server changes.
https://bugzilla.gnome.org/show_bug.cgi?id=682310
This code was originally here to close the summary box pointer if it was
already open, but it seems that it isn't necessary, and is causing all
sorts of problems.
Displaying a close button provides a discoverable way to close notifications.
Clicking the close button on new notifications, dismisses them, but doesn't
remove the notification source from the message tray if it is resident.
Clicking the close button on summary notifications acts the same way as clicking
"Remove" option in the right click menu, which is to remove the notification
stack and its source, even if it is resident or a tray icon.
