We now use meta_input_event_get_type() to discern input events from the
others. This commit has involved plenty of indenting changes, so it's
better seen with git diff -b.
When using the show-desktop shortcut with no desktop window, unshowing
will focus the second-most-recently-used window. If we find a desktop
window, it will be focused explicitly and everything works as expected;
however without a desktop window, we end up hiding the focus window,
which will use focus_default_window() with the not_this_one parameter
to move focus away. We used to get away with this, as the not_this_one
parameter was ignored until commit e257580b9484, now with bug 675982
fixed, we need to explicitly handle the show-desktop case.
https://bugzilla.gnome.org/show_bug.cgi?id=686928
On startup, workspaces are initialized according to the num-workspaces
preference. However when using dynamic workspaces, the actual number
of workspaces in use might be greater than the preference (when
replacing the window manager), forcing windows on those workspaces
to the first workspace.
To fix, ignore the preference completely when using dynamic workspaces
and try to restore the previous number of workspaces (as read from
_NET_NUMBER_OF_DESKTOPS).
https://bugzilla.gnome.org/show_bug.cgi?id=685439
Fixes bug #670396. Without this fix the guard window may not
extend over the whole area of the screen after a XRandR
reconfiguration. The effect being that mouse events are
delivered to invisible windows.
Moving focus immediately on crossing events as we currently do
in focus-follows-mouse mode may trigger a lot of unwanted focus
changes when moving over unrelated windows on the way to a target.
Those accidental focus changes prevent features like GNOME Shell's
application menu from working properly and are visually expensive
since we now use a very distinct style for unfocused windows.
Instead, delay the actual focus change until the pointer has stopped
moving.
https://bugzilla.gnome.org/show_bug.cgi?id=678169
If someone plugs in a new monitor, while all their regular windows
should move in absolute X coordinates to ensure they stay on the
same monitor, the desktop window should stay put.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
Simplify the set of window-property functions to remove the
unused functions:
meta_window_reload_properties_from_xwindow()
meta_window_reload_properties()
And to make:
meta_window_reload_property()
static. The code is considerably simplified by removing the
plural variants.
https://bugzilla.gnome.org/show_bug.cgi?id=587255
Plenty of ugly here, but it works; revert when the zenity version
we depend on stops being bleeding-edge (or we can assume a zenity
version that does not error out on unknown options).
https://bugzilla.gnome.org/show_bug.cgi?id=684306
Quotes should definitively part of the translation, but we are in
string freeze now - revert this when we get a string freeze approval
or after the freeze ends.
https://bugzilla.gnome.org/show_bug.cgi?id=684306
As plugins can now define their own keyboard shortcuts via
meta_display_add_keybinding(), it makes sense for them to
expose those shortcuts to System Settings, so add some API
to set the properties gnome-control-center uses to pick up
wm keybinding settings.
https://bugzilla.gnome.org/show_bug.cgi?id=671010
Commit 802c1ac4275 fixed updating the overlay key on settings
changes, but missed the case where the setting was set to an
empty value to disable the overlay key altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=682993
When changing the overlay-key setting, the change only takes effect
on restart - there are actually two bugs involved:
(1) the test whether the key has changed is located in the
else part of a test for string settings (and overlay-key happens
to be a string settings ...)
(2) with (1) fixed, a change signal is emitted, which triggers a
reload of all keybindings - unfortunately, the actual value
of overlay-key is only read on startup, so the key is reloaded
using the old value
Fix both issues by replacing the custom handling of the overlay-key
with the regular handling of string preferences.
https://bugzilla.gnome.org/show_bug.cgi?id=681906
When we consider tiling a special case of maximization, it makes
more sense to always unmaximize to the normal state rather than
restoring a previous tile state.
https://bugzilla.gnome.org/show_bug.cgi?id=677565
Currently we decide whether a modal dialog should be attached or not
when mapping it, i.e. we don't pick up preference changes that happen
while the dialog is up. It's not really a big deal given that modal
dialogs are usually transitory, but it's easy enough to add a bit of
extra polish ...
https://bugzilla.gnome.org/show_bug.cgi?id=679904
