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
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
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
We currently resync the stacking order of the two key frames
every iteration of the animation. This is costly and unnecessary.
This commit ensures they're stacked properly up front and doesn't
touch them after that.
https://bugzilla.gnome.org/show_bug.cgi?id=694993
Rather than expose a dizzying array of methods related to managing
state that require infecting every user of the overview methods, try
to do the sensible and smart thing internally. Now, the overview
itself tracks when XDND drags start, and simply calling show, hide or
toggle while an XDnD drag is in effect will show the overview, and
will only take the grab until after the XDND drag ends.
https://bugzilla.gnome.org/show_bug.cgi?id=663661
We currently call the session updated handler as soon as
the session modes are read. This handler sets up keybindings
for leaving the overview (if a user session) and shows the
login dialog (if a gdm session).
We can't do the latter until the stage is mapped because it
takes a grab, and we don't need to do the former until the
user goes into the overview.
This commit defers processing session updates until the
the layout manager says start up is prepared.
It fixes a race condition at login screen startup now that
we don't show the stage right away.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
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
For the HotCorner, we want to have different logic for tossing out
specific events based on the grabbed state, etc. so make us have
to pass in an event filter callback.
For the hot corner case, we want to have the pressure apply both in
and outside of the overview, so we need to move this to the user. At
the same time, use keybinding mode math that's more like what's used
in filterKeybinding.
While it may seem like an abuse of the KeyBindingMode API, it may
become more reasonable if one thinks of the pressure barrier as a
binding of sorts, just applied to the mouse. If a ButtonBinding API
was added to mutter, I think we'd use the existing KeyBindingMode
infastructure there as well.
Ensure that the pointer leaves the barrier before we trigger again.
For the message tray case, this doesn't matter much, as the trigger
won't have any effect after the grab is taken, but in the overview
HotCorner case, this ensures that we don't trigger the overview
transition many times simply by holding pressure against the hot
corner, which is easy to do accidentally.
Instead of sometimes having an event source and sometimes not, use
the empty event source when the session mode says the calendar is
disabled. This way, the code can assume an event source object and
avoid checks.
https://bugzilla.gnome.org/show_bug.cgi?id=641383
Check if the event source is currently doing an async call, and prevent
UI updates in that case. This avoids a flash of "No updates" when switching
months.
https://bugzilla.gnome.org/show_bug.cgi?id=641383
SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.
This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.
https://bugzilla.gnome.org/show_bug.cgi?id=693907
Toggling the overview during the startup animation reportedly
causes stuck grab and other odd behavior.
There's no reason to handle toggling the overview during this
time anyway.
This commit defers that handling until after startup.
https://bugzilla.gnome.org/show_bug.cgi?id=694837
Curently it is possible to copy the content of password entries,
and paste it elsewhere in clear text. This is undesirable, so
follow GTK+'s behavior and disable the copy action for password
entries.
https://bugzilla.gnome.org/show_bug.cgi?id=695104
We always leave the workspace switcher zoomed out when we can assume
that the user is actually making use of workspaces. For the default
dynamic workspace behavior, we make this assumption when more than
two workspaces are in use (e.g. at least two workspaces contain windows
plus an empty one at the end). However this test does not make sense
when using static workspaces - in that case, not using workspaces
would be indicated by a workspace number of 1 (in which case the
entire switcher is hidden completely), so add a check for dynamic
workspaces to the condition.
https://bugzilla.gnome.org/show_bug.cgi?id=695126
