This removes our Xwayland dependency in the native path. The direct
grabs are still there for the X11 backend and are a bit disgusting,
but that's OK. We can refactor it out later.
This introduces some pretty lousy hackery because it depends on
https://github.com/xkbcommon/libxkbcommon/pull/10 , and I really
don't want to wait on that to squash this dep.
Now that the internal mutter bindings and gnome-shell stopped using
META_KEY_BINDING_REVERSES, and after moving the 'adding shift reverses
the keybinding action' logic to gnome-control-center, we can remove
META_KEY_BINDING_REVERSES from mutter.
Plugin API is broken as this constant is removed from the exported
headers. ABI is broken as using this flag is now a noop.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
Currently the bindings for {switch,cycle}.* actions are created with the
META_KEY_BINDING_REVERSES flag so that <shift>+binding triggers the
reverse action. However, gnome-control-center does not know about this
kind of implicit bindings, and, for example, cannot warn when the user
tries to setup a conflicting <shift>+xxx binding.
These backward <shift> bindings are being explicitly set in
gsettings-desktop-schemas, so the META_KEY_BINDING_REVERSES annotation
can be removed for them from mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
MetaKeyBinding can be marked as being reversed
(META_KEY_BINDING_IS_REVERSED), but MetaKeyHandlerFunc callbacks
cannot check whether this flag was set or not on the MetaKeyBinding
which triggered the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=732295
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
Now that we always use XKB, it's very unlikely that we'll get a
MappingNotifier without a subsequence XkbKeymapNotify event. Just
do all the work always.
This will also help us considerably for the future when we'll be
putting the keymap event in the backend.
At this point there shouldn't be any system capable of running mutter
that doesn't have it and we're introducing functionality like setting
the keymap that has an hard requirement on it.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
We really can't do this unless the backend X server is the same as the
frontend X server, as we pass a frontend XID to the backend, which is
only the case when we're not a Wayland compositor.
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.
For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.
This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.
Expect some regressions from this. Sorry for any temporary regression
that this might cause.
The last commit added support for the "appmenu" button in decorations,
but didn't actually implement it. Add a new MetaWindowMenuType parameter
to the show_window_menu () functions and use it to ask the compositor
to display the app menu when the new button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
meta_window_get_position() returns the client rect position, which
we then pass to meta_window_move_frame. Just use the existing frame
rect coordinates.
It looks weird to have Alt+Space pop up under the cursor instead
of the top-left corner of the window, and the Wayland request will
pass through the coordinates as well.
Add it to the compositor interface, and extend the
_GTK_SHOW_WINDOW_MENU ClientMessage to support it as well.
If we exit early as not handled, then the normal process_event
handler will fire, and trigger the overlay-key binding. As that's
a special binding that doesn't have a handler, trying to trigger
that handler will crash mutter.
Instead of returning early, just check for xdisplay every time
we try to drive the X grab state machine. We really need a better
solution for this on the Wayland side.
Commit 585fdd781c not only removed the tabpopup, but set invalid
handlers (a.k.a. NULL) for those shortcuts; add back handling of
basic handling of those shortcuts by switching instantly without any
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=728423
A careful analysis of mutter's codebase shows that nothing actually
passes anything but 0 to this. gnome-shell has one instance, but it's
most likely a mistake.
Remove the grab_mask field and the one place in keybindings.c that uses it.
The parameter to begin_grab_op is left in for API compatibility reasons.
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.
We still keep MetaScreen in the public compositor API for compatibility
purposes.
We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.
With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.
We also kill off active_screen at the same time, since it's
not necessary anymore.
A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
We don't want to match the keysym so that e.g. an accelerator
specified as "<Super>a" works if the current keymap has a keysym other
than 'a' for that keycode which means that the accelerator would
become inaccessible in a non-latin keymap.
This is inconvenient for users that often switch keyboard layouts, or
even have different layouts in different windows, since they expect
system-level keybindings to not be affected by the current layout.
https://bugzilla.gnome.org/show_bug.cgi?id=678001
We must spoof events to clutter even if they are associated
with a MetaWindow, because keyboard events are always associated
with one (the focus window), and we must process keybindings
for window togheter with the global ones if they include Super,
because we're not going to see them again.
The handler pointer is dangling in MetaKeyBinding until
rebuild_key_binding_table() is run, so we can't dereference it.
Because we only need the flags at ungrab time, store a copy
in the MetaKeyBinding structure.
https://bugzilla.gnome.org/show_bug.cgi?id=724402
This reverts commit ebe6e3180e.
This is wrong, as mutter's controlling TTY may not be the same
as the active VT, and in fact won't be in the case of systemd
spawning us.
The "correct" API for this is to use David Herrmann's
"Session Positions" system to switch to another VT:
http://lists.freedesktop.org/archives/systemd-devel/2013-December/014956.html
Currently the only way to move a window to another monitor via
keyboard is to start a move operation and move it manually using
arrow keys. We do have all the bits of a dedicated keybinding in
place already, so offer it as a more comfortable alternative.
https://bugzilla.gnome.org/show_bug.cgi?id=671054
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
