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
The notifications spec has two hints for playing a sound, sound-file
and sound-name. We can support them using the existing code that
wraps libcanberra.
https://bugzilla.gnome.org/show_bug.cgi?id=642831
The message tray currently operates in three modes: in the overview,
normal, and while the on-screen keyboard is up. The last case is
particularly odd, and exclusively used for chat-notifications. As
users can still use the Chat application directly on touch-only
devices, the additional mode isn't really justified, so remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=662687
A pressure barrier is a barrier that activates after the user pushes
against the bottom of the screen in a short time. Implement this using
the new XInput 2.3 features that provide extended information about
pointer barriers, and use it so that pushing against the bottom of
the screen edge brings up the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
While it is possible to keep track of removed sources by tracking
their summary items' actor:.destroy signal, a dedicated signal
mirroring the existing 'source-added' one is more convenient.
https://bugzilla.gnome.org/show_bug.cgi?id=693220
The designs says that only music notifications should be shown in full
in the screenshield, the others should be either shown as a summary or
with very light details.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
Allow message tray sources to provide a NotificationPolicy object,
that will configure how and if the source is displayed. For notification
daemon sources, this object is hooked to GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=685926
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
