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
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 cut/copy actions 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
Currently both the app switcher and the thumbnail list divide items
first into two groups (based on whether the item is located on the
current workspace or not), and then sort each group individually
by MRU.
The resulting behavior is often confusing, e.g. when using alt-tab
a second time does not switch back to the original window when the first
invocation involved a workspace switch and the workspace contains
windows of more than one application.
Instead, make the behavior more predictable by sorting both lists
strictly by MRU.
https://bugzilla.gnome.org/show_bug.cgi?id=661156
Shell modal dialogs can take their action on a certain key's
key-release-event. For example on <enter> the affirmative action is
usually run.
Make sure that the key was also pressed on the dialog and we're not
seeing a spurious key-release-event from a key that was pressed before
the dialog was displayed.
https://bugzilla.gnome.org/show_bug.cgi?id=692937
It is possible that a session survives after closing, if any processes
(usually PulseAudio and GConf) are still alive at the end. In that case,
ignore it, as the user is already logged out and there is nothing to lose.
https://bugzilla.gnome.org/show_bug.cgi?id=695002
Implement a basic OSD popup that shows an icon and optionally a label
and a fill level. It is based on the existing OSD implementation in
gnome-settings-daemon, which it will replace.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Right now we take a still frame of the desktop before showing the
start up animation. This gives us an animation over what was
there before startup.
That's not actually desirable when restarting the shell. We don't
want to animate over undecorated windows, we really want to animate
over the noise texture.
This commit drops the still frames in favor of the noise texture.
https://bugzilla.gnome.org/show_bug.cgi?id=694326
Particularly when using asian languages the symbol could become large
enough to not fit in the space we have and we'd end up with a totally
ellipsized item.
https://bugzilla.gnome.org/show_bug.cgi?id=695001
Doing so causes useless full stage redraws and breaks culling
as clutter cannot know how the signal handler affects painting.
So use clutter_threads_add_repaint_func_full instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694988
Previously, the overview BoxLayout was sized and positioned explicitly
using the primary monitor coordinates, as its parent was at 0,0 and
with a fixed layout manager. Now we use a bin layout, so we need to
position and size the stack actor, and set the overview boxlayout to
expand.
Take also the occasion to use a MonitorConstraint instead of handling
position and size manually.
https://bugzilla.gnome.org/show_bug.cgi?id=694969
We used to clip the overview group to prevent the dash from sliding into
neighbor monitors, but now it moved to the groupStack, so we must move
the clip too.
https://bugzilla.gnome.org/show_bug.cgi?id=694970
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
We generally want view content centered, in particular where the
view itself is symmetrical. So move the dash to a separate layer
and use a placeholder to account for its size when showing the
window picker, which is the only view where it doesn't make sense
to center the content.
https://bugzilla.gnome.org/show_bug.cgi?id=694261
Commit 43ed66cf26 changed the toplevel overview actor, so it
makes sense to change the show/hide transitions to use that instead
of the existing group, to avoid elements layered on top of the
group being excluded from the transitions.
Windows can sometimes be focused, or appear to be focused, without being
at the exact top of the stack, for example in the case of override-redirect
windows, or with attached modal dialogs. In that case, we should not
try to minimize them (as it creates a loop that makes it impossible to restore
the window)
https://bugzilla.gnome.org/show_bug.cgi?id=694905
