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
