Activating the overview is fairly easy (hot corner, <super>), so doing it
automatically after closing the last window on a workspace does not save
a lot of effort; it does result in a surprising context switch when the
user does not expect the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=662581
Unfortunately, display configuration can and does fail, due
to unspecified HW constraints, drivers bugs, unsupported exotic
configurations or just bad luck.
So when the user makes a change in the control center, show
a dialog asking him if it looks OK, and revert back after 20 seconds
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=706208
We've long had the hasWorkspaces property, but it doesn't seem like
it was ever used. Implement it so that we don't have workspaces in
initial-setup mode.
Since it's difficult to make it change at runtime with a decent set
of semantics, and we never expect that to happen, don't bother
implementing it dynamically.
https://bugzilla.gnome.org/show_bug.cgi?id=698593
We currently monitor the shell's override schema for changes to
the 'dynamic-workspaces' key, which ends up being the wrong
schema in classic mode. With the new ability to use mode-specific
overides, we can finally fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=701717
Currently we show the workspace popup for relative targets ("up", "down"),
but not when targetting a specific workspace directly.
There is not really a good reason for that difference, and as we are about
to introduce a new shortcut to target the last workspace (which does vary
with dynamic workspaces), it makes sense to unify the behavior and always
show the switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=659288
It makes sense to allow closing the app menu with the same shortcut
that is used to open it, so make it a toggle action and allow it
TOPBAR_POPUP mode.
https://bugzilla.gnome.org/show_bug.cgi?id=686756
Alt-Tab away from a monitor sized on the primary monitor results into the top
panel being displayed on top of the window which looks very bad.
So just hide those windows by minimizing them.
The icon geometry animation does not really make sense for fullscreen windows
so just fade them out.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
meta_display_add_keybinding() returns a keybinding action ID for
dynamically registered keybindings which can be used to match a
keycode/mask pair to the action it is bound to.
https://bugzilla.gnome.org/show_bug.cgi?id=682315
We previously scaled windows to (primary.x, 0), which is wrong if the
primary monitor is not at y == 0. At the same time, change the policy
to pick the hot corner on the monitor the window is on, because that's
closest to where it will appear in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
If we overwrite a map animation (for example because the actor is now destroyed),
we need to complete it first, otherwise it starts off from a random
middle point. This is the same treatment opacity gets for normal windows.
https://bugzilla.gnome.org/show_bug.cgi?id=690241
Now that we use the new 'switch-applications' keybinding for the
application-based alt-tab popup, we can use the 'switch-windows'
keybinding for a more traditional switcher.
Based heavily on the alternate-tab extension from Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The Shell's alt-tab popup is application-based, so using the
'switch-windows' keybinding for it never really made sense.
Use the newly added 'switch-applications' keybinding instead.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The original condition the property was based on was added to make
the a11y switcher available in the login screen, though it did never
work properly - after popping up the switcher, additional tab key
presses were ignored. As we are now able to filter bindings much more
selectively, we can simplify the check and drop the sessionMode property.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
With the new flexible system in place, there's no point explicitly
hardcoding some built-in keybindings; just use the generic mechanism
for everything.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Currently we hardcode the set of keybindings that are available in the
overview; add a generic mechanism to specify in which KeybindingModes
a keybinding should be available.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
We are currently using a hack to allow a select set of keybindings
in the overview. Implement the new MetaPlugin keybinding_filter
hook, which provides a cleaner way to achieve the same.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
The fade animation we started using after centering attached
modal dialogs didn't work too well. So after going back to the
scale animation, adjust it to scale from the center rather
than the top, which works quite well.
https://bugzilla.gnome.org/show_bug.cgi?id=681601
The combination of desaturating and lowering the brightness does
not work too well in all cases, in particular for applications
using the dark theme variant. Dropping the desaturation effect and
making the brightness adjustment more profound gives a better
result.
https://bugzilla.gnome.org/show_bug.cgi?id=681601
Changing the number of workspaces while the popup was visible (which
happens when moving windows on the last non empty workspace) resulted
in a wrong layout. Fix that, by listening to workspace-added and
workspace-removed signals, and by always requesting an updated size
from the actor.
https://bugzilla.gnome.org/show_bug.cgi?id=679005
While modal dialogs were attached to the parent's titlebar, it
made sense to leave the top of the parent window at full color.
With the new position of modal dialogs, it makes more sense to dim
the entire parent window, so we can use a combination of Clutter's
BrightnessContrast- and DesaturateEffect instead of our own custom
shader.
https://bugzilla.gnome.org/show_bug.cgi?id=674499
With modal dialogs no longer being attached to their parents'
titlebar, the current animation no longer works too well. Use
a simple fade animation instead.
https://bugzilla.gnome.org/show_bug.cgi?id=674499
Right now the "move to workspace" keyboard shortcut transition isn't smooth. It
shows the window disappearing, hopping to the next workspace, and then sliding
into view. "Pin" the window to the stage while the animation is in progress,
then release it afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=660839
Install a custom handler for move-to-workspace-* keybindings that
shows the workspace switcher, which gives the user a sense of
direction when navigating with the keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
Most of code implementing workspace switches was repeated with
minor differences on each direction. Instead, consolidate it
and use the new meta_workspace_get_neighbor.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
With the application menu now being more than a stub, it has
become a much more interesting target, so add a keyboard shortcut
to open it directly.
This should also ease some of the pain for focus-follows-mouse users.
https://bugzilla.gnome.org/show_bug.cgi?id=672909
