Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
Move to center uses all monitors for calculating work area.
This can lead to an unexpected behaviour on some monitor
configurations resulting in current window being split between
monitors. We should move window to the center of the active display.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1073
Make sure it is only the special modifier (hardcoded to 1 currently)
which is being pressed (not counting locked modifiers) before notifying
that the special modifier is pressed, as we are interested in it being
pressed alone and not in combination with other modifier keys.
This helps in two ways:
- Pressing alt, then ctrl, then releasing both won't trigger the locate
pointer action.
- Pressing alt, then ctrl, then down/up to switch workspace won't interpret
the last up/down keypress as an additional key on top of the special ctrl
modifier, thus won't be forwarded down to the focused client in the last
second.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/812https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
If you first press a key that triggers the "special modifier key" paths
(ctrl, super), and then press another key that doesn't match (yet?) any
keybindings (eg. ctrl+alt, super+x), the second key press goes twice
through process_event(), once in the processing of this so far special
combination and another while we let the event through.
In order to keep things consistent, handle it differently depending on
whether we are a wayland compositor or not. For X11, consider the event
handled after the call to process_event() in process_special_modifier_key().
For Wayland, as XIAllowEvents is not the mechanism that allows clients see
the key event, we can just fall through the regular paths, without this
special handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
After the introduction of locate-pointer (commit 851b7d063 -
“keybindings: Trigger locate-pointer on key modifier”), inhibiting
shortcuts would no longer forward the overlay key to the client.
Restore the code that was inadvertently removed so that inhibiting
shortcuts works on the overlay key again.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/734
We don't strictly need it for wayland compositors, yet there are
paths where we try to trigger those passive grabs there. Just
skip those on the high level code (where "is it x11" decisions
are taken) like we do with passive button grabs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
On X11, mutter needs to keep a grab on the locate-pointer key to be able
to trigger the functionality time the corresponding key combo is
pressed.
However, doing so may have side effects on other X11 clients that would
want to have a grab on the same key.
Make sure we only actually grab the key combo for "locate-pointer" only
when the feature is actually enabled, so that having the locate pointer
feature turned off (the default) would not cause side effects on other
X11 clients that might want to use the same key for their own use.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/647
Some special modifiers (typically "Control_L" used for locate-pointer in
mutter/gnome-shell or "Super_L" for overlay) must be handled separately
from the rest of the key bindings.
Add a new flag `META_KEY_BINDING_NO_AUTO_GRAB` so we can tell when
dealing with that special keybinding which should not be grabbed
automatically like the rest of the keybindings, and skip those when
changing the grabs of all keybindings.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/685
We use the combination of pressing Super and clicking+moving the mouse
to drag windows around and we also support pressing Super and using the
touchscreen to drag windows.
Since we don't want to show the overview when the Super key was used to
initiate a window drag, prevent showing the overview in case a
TOUCH_BEGIN or TOUCH_END event happened during the key was pressed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/228https://gitlab.gnome.org/GNOME/mutter/merge_requests/495
The external grab handler is shared across all external bindings and external
bindings have now different binding flags. For this reason, when rebuilding the
binding table there could be loss of information if we assign the bindings flags
of the external handler to all external bindings. Let's store the bindings flags
in MetaKeyGrab too and use this when rebuilding the binding table to avoid the
above issue.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/169
The "force restore shortcuts" being triggered by a key-combo, there is
no guarantee that the currently focused window is actually non-NULL in
which case we would crash.
Make sure there is a window currently focused before trying to restore
the shortcuts on that window.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/464
Moving windows using `move-to-side-X` and `move-corner-XX` keybindings
should keep windows within the confines of current screen.
`move-to-monitor-XXX` keybindings can be used to move windows to other
monitors.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/320
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
When a Wayland client issues a shortcut inhibit request which is granted
by the user, the Super key should be passed to the surface instead of
being handled by the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=790627
The reason why multiple keycodes could be mapped to a single keysym was
to support having both KEY_FAVORITES and KEY_BOOKMARK map to
XF86Favorites. However, iterating through all layout levels adding all
key codes has severe consequences on layouts with levels that map
things like numbers and arrow. The result is that keybindings that
should only have been added for keycodes from the first level, are
replaced by some unexpected keycode where the same keysym was found on
another level.
An example of this is the up-arrow key and l symbol. Normally you'd find
both the up-arrow symbol and the l symbol on the first level and be done
with it. However, on the German Neo-2 layout, layout level 4 maps the
KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.
Which ever gets to take priority is arbitrary, but for this particular
case KEY_E incorrectly mapped to up-arrow instead of the l symbol,
causing the keyboard shortcut Super+l, which would normally lock the
screen, to trigger the workspace-up (Super+up-arrow) key binding.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
Currently tiled windows are not resizable and their size is fixed
to half the screen width. Adjust the code to work with fractions
other than half, and allow users to adjust the split by dragging
the window edge that is not constrained by a monitor edge.
Follow-up patches will improve on that by resizing neighboring
tiled windows by a shared edge, and making the functionality
available to client-side decorated windows implementing the
new edge constraints protocol.
Now that the preview tile mode has been split from the window's
tile_mode property, it is much more natural to pass the requested
tile_mode to the tile() function instead of setting it externally
and calling the function to apply the state.
The existing semantics of the tile_mode property are terribly confusing,
as it depends on some other property whether it represents the requested
or current mode. Clear this up by just using separate variables for the
two. As it is unlikely that we will ever support more than one tile
preview, we can track the requested mode globally instead of adding
another per-window variable.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
If a non-latin based keyboard layout is active, for example Cyrillic,
keybindings won't work unless we resolve the bound keysyms on a
secondary latin based layout. So, to make keybindings work on non-latin
based layouts, detect if a keymap doesn't have all of the basic latin
letters (a-z) and resolve from an additional US layout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
Add the infrastructure to resolve keybinding symbols from multiple
layouts. It is still unused, but will be, when the primary layout does
not have the required latin keysyms in it.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
When resolving what keycodes a key binding resolves to, only look up
key codes from the current layout group. Without this, unwanted
overlaps may occur. For example when a keymap has both a dvorak and a
qwerty layout on different layout groups, one keybinding may be bound
on multiple keys, arbitrarily "shadowing" another.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
