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
We may release the focus grab at any time, so it's not guaranteed
we'll be in event processing. In particular, hovering over and out
of a notification will cause this to happen, as the notification
is hidden on a timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=695659
Pointer tracking is broken when the pointer is over the stage input
area. This is apparently fallout from mutter going to XInput2.
This commit changes the mouse event handling code to also use XInput2.
https://bugzilla.gnome.org/show_bug.cgi?id=695324
In order to center the view selector, the dash has been moved to a
separate layer, which means that it will overlap the app picker and
search results if the available width is smaller than the maximum
width that the content will request. Fix this by adding enough
horizontal padding to account for the width the dash will have at
its largest icon size.
https://bugzilla.gnome.org/show_bug.cgi?id=695471
For the same reasons that we disable the tray barrier, we should
disable hot corners as well -- when users have a full-screen game
open, we shouldn't allow overview activation by the hotcorner.
https://bugzilla.gnome.org/show_bug.cgi?id=694997
gnome-panel is going away in 3.8, so we can't rely on it to provide our
friendly and reliable companion. But no regret, because we can ship it
ourselves, and at the same time remove some unnecessary configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=695526
Launching the run dialog to open the looking glass or something
like that shouldn't install a bunch of file monitors that monitor
every IO change to the home and system directories.
Instead, simply scan all the paths when trying to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=695338
Application view: the radius of the corners on the hover effect
should match the radius of the prelight effect that is used for
running apps. Original fix from Bharath Thiruveedula.
https://bugzilla.gnome.org/show_bug.cgi?id=691578
With fallback mode gone, we can no longer rely on gnome-screensaver
being installed. Rather than handling three different cases (GDM,
gnome-screensaver, no lock), disable the lock functionality when
not running under GDM.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
With fallback mode dropped, we can no longer rely on gnome-screensaver
to be installed, so we'll have cases where we are unable to lock the
screen. The user menu should not show the "Lock" item in this case,
but as UnlockDialog includes UserMenu, we cannot use the existing check
without creating a circular dependency; move the function to a more
generic place to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=693403
