Multiple settings objects could have the same key, so that alone
is not enough to identify the binding. Add also the pointer value
of the GSettings object.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Previous commit moved policy for keybindings when grabbed down to
the handler, but did not replay the event if it is was not handled.
This commit adds the missing bit.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Do not ignore all key events automatically when a compositor grab
is active, and introduce a flag for masking which keybindings should
be active.
This does not mean that automatically all keybindings are active
when the compositor is modal, it merely moves the policy down to
the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
Instead of requiring a GSettings object, allow to hardcode a specific
combination for a keybinding. This will be used by the Shell to
replace the media keys plugin in gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=613543
The X server sends a XkbNewKeyboardNotify event for each keyboard
device when a new keyboard description is loaded. These days a typical
computer has several keyboard devices, e.g. xinput on this laptop
lists 8. Since the work we do on these events is relatively expensive
and we are only really interested in changes to the virtual core
keyboard we can skip other devices' events to cut on needless work.
https://bugzilla.gnome.org/show_bug.cgi?id=674859
Using ClutterEffect is not pratical on MetaBackgroundActor, as the FBO
redirection has a noticeable performance impact. Instead, allow adding
GLSL code directly to the pipeline used to draw the background texture.
At the same time, port MetaBackgroundActor to modern Cogl API.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
When support for multiple plugins was removed, the logic that was
supposed to send events to Clutter directly *only if there is no filter
function from a plugin* was broken, so events were being sent to
Clutter twice if Clutter didn't consume them the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=686406
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 e257580b94, 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.
