Instead of using the notification's own actor as a banner (and
keeping it around after the banner was displayed to not dismiss
the notification itself), create a separate banner actor from
the information the notification provides, just like we do for
lock screen and message list notifications.
This change breaks notifications with custom content, but only
temporarily - we will soon provide a hook to allow customizations
again.
We no longer have a single notification actor that is either displayed
as banner or reparented to the summary depending on state - both the
lock screen and the notification section of the message list create
their own UI based on the information attached to the notification
object. Adding to this that different representations of a notification
may now exist simultaneously (as they are included in the message list
immediately rather than after the banner has been displayed), it no
longer makes sense to keep the banner actor in the notification itself.
Add a new NotificationBanner class that provides a separate banner
implementation based on the message list's NotificationMessage that will
soon replace the existing notification banners.
Both the screen shield and the notification section in the message
list create their own UI for notifications rather than using the
notification actor itself. Currently there is no clean way for such
representations to include notification actions - we will need this
as we will soon use a separate actor for banners as well, so keep
track of actions added via addAction().
St's hover tracking uses ClutterInputDevice, which unfortunately may use
an outdated cursor position to determine which actor is hovered. Using
MetaCursorTracker instead would fix this, but would require linking St with
libmutter - avoid this for now by manually fixing up Clutter's view of
the pointer position in the case where we rely on it working properly.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
While applications can no longer spam the users with a constant stream
of banner notifications, it is still possible to drown the summary in
the message list. Avoid this by limiting the number of notifications a
single source is allowed to display simultaniously.
test-xy-stress in libnotify's tests suddenly became fun again ...
https://bugzilla.gnome.org/show_bug.cgi?id=744850
We want to shield users from being overloaded by an overwhelming stream
of notification banners, either due to coming back from idle/lock or
because an application is misbehaving. Previously we replaced all queued
notifications with a summary notification in that case, but now that
notifications appear in the summary immediately, we can simply stop
adding them to the queue and rely on the date menu to convey that
information to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The summary may contain notifications that have not been seen by the user
and won't be shown as banner. Currently this is only the case for resident
notifications that are emitted by the focused app, but it will become more
common as we will start limiting the number of queued notifications.
Indicate to the user that more notifications are available by displaying a
small dot in the top bar button.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Source::count-updated is emitted as notifications are added or removed,
which is correct for the primary notification count. However it is not
for the unseen count, which will also change when a notification is
acknowledged without being removed. At the moment this does not matter,
as the unseen count is only used on the screen shield and notifications
are never acknowledged while the screen is locked. However we will soon
use the unseen count in the normal session as well, so emit the signal
in this case too.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Using a "There are too many notifications" notification is a bit odd,
and we will address the issue differently soon. So rather than update
the notification to do something else than opening the mostly empty and
useless tray when clicked, remove it altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
No Source subclass used it to do anything special, and with sources
no longer having any UI representation on their own, doing anything
else isn't useful either, so just kill off that hook.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
It was a nice feature, but with sources no longer being represented in
the UI, there is no longer a way for users to make use of it. If we want
to bring the feature back in the future, it would probably make more
sense to implement via the chat source's policy anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
The notification list in the calendar drop-down now functions as summary
area, so we can drop it from the message tray and remove a lot of complexity
from the state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since notification support was added to the lock screen, notifications
are no longer necessarily represented by the actual notification actor
anymore. However when an existing notification is updated, external
representations currently become outdated.
Emit an appropriate signal which allows them to update.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
Music is no longer a special type of notification according
to the design. If we want to resurrect the functionality, we
can reimplement it with a dedicated API like MPRIS rather
than piggy-bagging on the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Tray icons make for a terrible UI on their own, but trying to
shoehorn them into the notification system has only made them
worse. At least for the time being this removal is temporary
and support for tray icons will be back, but no longer as part
of the notification system.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Just like keybindings and the message tray pointer barrier, gestures
don't always make sense - for instance, swiping up the screen shield
should not trigger the message tray just as the SelectArea action around
the left edge should not open the overview.
To avoid this, restrict gestures based on the current keybinding mode.
https://bugzilla.gnome.org/show_bug.cgi?id=740237
It is really annoying for the user to acknowledge multiple notifications
when they queue up. So, to prevent a notification flood that has to be
handled by the user one-by-one, a summarized-notification feature is
added which leaves a single summarized-notification for the user,
replacing multiple notifications if the number exceeds 1, which they may
or may not acknowledge. When this summarized-notification is acknowledged,
the message-tray is opened where they can view the notifications that were
summarized. This helps the user concentrate on his primary task
simultaneously informing them about the new notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=702460
The summary container will trap the focus if any sources are present,
making the message tray menu unreachable by keynav. Apply the same
hack as in searchDisplay and add a focusTrap to move the focus manually
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=707799
When the pointer leaves the notification area, we queue a timeout to
hide the notification after a little while. If the user is hovering over
a notification and clicks the X button to close the notification, we will
destroy the notification, which causes a "pointer left" event on the
notification area. This queues a timeout which erroneously fires after
the next notification in the queue shows up.
The code and state machine are too complex to properly make sure this
timeout doesn't fire when there is no notification up next, so instead
just clear it when showing a notification to make sure that any
previously queued timeout doesn't apply to us.
https://bugzilla.gnome.org/show_bug.cgi?id=731118
If the notification is updated while SHOWING, we'll overwrite the
tween updating it to the new 'y' position, but forget to update the
state to SHOWN at the end of our transition. Make sure to always set
the state to SHOWN at the end.
https://bugzilla.gnome.org/show_bug.cgi?id=704844
Doing so is inconsistent with the behavior in the summary, and
is quite annoying when dealing with chats (because there is no way
to unfocus a chat notification with the keyboard only)
https://bugzilla.gnome.org/show_bug.cgi?id=724178
Commit b7e1539699 removed the size to support hidpi but that caused the
actor to no longer be square. Fix that by going back to setting a size
but apply the scale factor before doing so.
Split the current implementation of SourceActor into
SourceActor and SourceActorWithLabel.
In this manner we can use source actors withouth count labels,
required in the screenShield to not clash with the count
text label.
https://bugzilla.gnome.org/show_bug.cgi?id=709275
If the notification is destroyed between an allocate and the redraw,
the meta_later is invoked on a destroyed object, and fails because
the clutter calls are invalid at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=722547
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
For mysterious reasons I'm not sure of myself, navigate_focus will only focus
mapped actors. So, make sure the widget is showing before navigating to it.
https://bugzilla.gnome.org/show_bug.cgi?id=709853
The methods we call in _updateState may not be reentrant, so make
sure that we never get into a situation where _updateState, through
some crazy chain of events, calls itself.
https://bugzilla.gnome.org/show_bug.cgi?id=711694
When a notification becomes expanded, it's either already shown,
or in the process of being shown. Don't set the state to SHOWING
again, which confuses our state machine.
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Otherwise, when closing the tray, we'll try to focus an actor, which will
focus the stage window, which will drop the focus from whatever window we
already had focused.
https://bugzilla.gnome.org/show_bug.cgi?id=710347
If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
NotificationDaemon doesn't pass a gicon to the Notification constructor,
because it calls .update() immediately after, so messageTray.js
calls into Source.createIcon(), which returns null and crashes.
Instead, shortcut the Notification constructor by skipping
.update() completely.
https://bugzilla.gnome.org/show_bug.cgi?id=709998
According to the designs, the notifications switch was supposed
to move from the user menu to the new message tray menu. However
so far the new system status implementation only removed the old
switch, so add it back in its new place now.
https://bugzilla.gnome.org/show_bug.cgi?id=707073
_updateState has a lot of variables that sort of gunk up the
code and make it more unreadable than need be. Clean up the logic
a lot by moving those variables into the places that they actually
matter, renaming them to remove prefixes, and remove some conditions
that are always met.
Right now the code chooses to animate based on whether or not the
notification was "removed", which is quite a sketchy subject. For
now, add an additional case so that we don't animate when we transition
to the lock screen.
Using a signal handlers causes us to depend on connection order, but
we need the message tray code to run last, so it can notice that
notifications are destroyed when hiding the boxpointer and skip
the broken animation.
https://bugzilla.gnome.org/show_bug.cgi?id=686855
We can easily implement much of the same behavior ourselves by
keeping track of Clutter's focus events. Reintroduce heavily
modified FocusGrabber to do the work for us.
This will temporarily break when the user selects a window until
we can make gnome-shell automatically set the stage focus.
This also removes our only use of focus grabs, so remove those
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
If we focus notifications before they're expanded, the body and action
area won't be visible, and the can_focus members like the text entry
will not be able to be focused.
Ensure that all of the all actors that would be in an expanded notification
are visible before we attempt to focus them.
https://bugzilla.gnome.org/show_bug.cgi?id=698778
Commit d0310bd745 blindly replaced global.overlay_group with
Main.layout.overviewGroup, but unlike the former, the latter is
hidden while the overview is not active, which makes it unsuitable
for the message tray's light box. In fact, with the removal of
global.overlay_group, there is no longer a container which may
be used both inside and outside the overview, so we can either
recreate the lightbox each time we show/hide the overview, or
use different lightboxes altogether; this opts for the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=701097
Variable names like "sourceNotificationStackDoneShowing" are too
long, and too undescriptive: this one points to a source, not a
notification stack that has been done showing.
The point of a hash table is that you don't need to list all the
elements. To avoid that, keep a "clearableCount" in MessageTray,
which can be used by the message tray menu to show and hide the
clear item, and that is updated in constant time when sources
are added or removed.
https://bugzilla.gnome.org/show_bug.cgi?id=700194
Since we now have global.screen::in-fullscreen-changed, remove the
duplicate signal. To prevent ordering problems in connecting to
this signal, make inFullscreen a property-function of a new Monitor
object rather than a data property we tack on to a Rectangle object.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
As the context menu and notification boxpointer can only appear if we already
take a modal grab, grabFocus will have problematic results if the focus does
somehow change.
https://bugzilla.gnome.org/show_bug.cgi?id=698483
Putting the notification actor in the tray actor has caused a lot
of various bugs and glitches over the years related to syncing the
two, fizzling out events, and so on. It's a much simpler model if
we consider the notification actor and tray to be separate widgets.
As a side effect, this makes the context menu not pop up when we
right-click on notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=695800
This does nothing while the tray is active, so it doesn't make sense
to track it on the tray. This also makes the code a lot easier to read,
with notification behavior being labeled "notification" rather than
"tray".
https://bugzilla.gnome.org/show_bug.cgi?id=695800
notify::* doesn't guarantee that the value has changed, only that it
may have been. We need to ensure that we track the old value to make sure
we don't do things like overwrite timeouts if they already exist.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
Now that the tray is modal, the summary is tied to the tray,
and we don't need to have separate states for the tray and
summary. This also removes the nearly invisible opacity tween
on the summary items when opening the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
The only way that locking happens is with when the summary box
pointer is active. As it can only happen if the summary state
is active, it's impossible for a notification to be expired,
or the summary to be hidden while it's showing.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
It makes more sense to use the monitor the tray is on, rather than the
primary monitor. This also matches us with whether we can open the tray
from a barrier/dwell or not.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
This cleans up the code considerably, and makes it so that
one path creates all hot corners for all monitors. Why this
wasn't done originally, I have no clue...
The one complication is debouncing if the button and hot corner
are triggered in rapid succession, so we just move this tracking
to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
This filters out resident and transient notifications in the normal
case, but just returns the number of unread messages for the Telepathy
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=687787
The complex overview transition code means that there's no easy
way to handle with this right now. Blocking the message tray
while the overview is animating seems like the correct thing to do.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
The activities button may come and go at any moment now that we
have a dynamic panel. We need to re-check the activities button
whenever the panel is updated.
https://bugzilla.gnome.org/show_bug.cgi?id=694038
Don't show the message tray in the overview by default. From now on the
message tray in overview behaves as regularly, i.e. it will slide up the
overview on Super+M keypress.
https://bugzilla.gnome.org/show_bug.cgi?id=693987
ScreenShield uses Notification.bannerBodyText to fill the body of detailed
notifications, so use a separate boolean property to indicate it was already
added to the body.
https://bugzilla.gnome.org/show_bug.cgi?id=693822
