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
Add a mechanism to MetaWaylandSurface that inhibits compositor's own
shortcuts when the surface has input focus, so that clients can receive
all key events regardless of the compositor own shortcuts.
This will help with implementing "fake" active grabs in Wayland and
XWayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Moved from g-s-d's media keys plugin, where it was called "video-out",
since it requires changing the current monitor configuration and we
want to remove the old DBus API.
This implementation is intentionally simple and not really meant for
more than debugging and validating the various configurations. A
better user experience will be introduced in gnome-shell with a custom
keybinding handler.
The default value includes <Super>P in addition to the standard keysym
for historical reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
Moved from g-s-d's media keys plugin, where it was called
"video-rotate", since it requires changing the current monitor
configuration and we want to remove the old DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
A single keysym can resolve to multiple keycodes. Instead of only using
the first one and ignoring the others, we store all codes in
MetaResolvedKeyCombo and then handle all of them in keybinding
resolution. If we already have bound a keycode for a keybinding with a
specific keysym then this can get overwritten by a new keybinding with a
different keysym that resolves to the same keycode. Now that we resolve
and bind all keycodes for a keysym this might happen more often; in that
case warn but still overwrite, but only for the first keycode for each
keysym. If a secondary (i.e. all non-first keycodes) is already indexed
we just ignore that; this should resemble the old behavior where we
only took the first keycode for any keysym as close as possible.
https://bugzilla.gnome.org/show_bug.cgi?id=781223
Function "handle_raise_or_lower (src/core/keybindings.c)" is called
when running 'raise-or-lower' on a window. This function iterates
through all the windows in the stack to determine if our window is
already on top or obscured. The problem is that the window stack
includes windows in another workspaces and also windows that are
minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=705200
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We currently only focus unfocused windows on button press if no
modifiers (or just ignored modifiers) are in effect. This behavior
seems surprising and counter-intuitive so let's do it for any modifier
combination instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
There's no reason to keep this ~15 year old piece of code around as
well as the preference handling that would only make sense if this
hunk was actually enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
meta_parse_accelerator() considers 0 length accelerator strings as
valid, meaning that the keybinding should be disabled. Unfortunately,
it doesn't initialize the MetaKeyCombo so if the caller doesn't
initialize it either, we end up using random values and possibly
grabbing random keys.
https://bugzilla.gnome.org/show_bug.cgi?id=766270
The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.
This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
MetaKeyCombo is about the *unresolved* keybinding, which can either be a
"keysym" (<Ctrl>F) or a "keycode" (<Ctrl>0x21). When we resolved the
keysym to a keycode, we stuffed it back in the same MetaKeyCombo, which
confused about what the "keycode" field was for. Thus, we often stomped
on the user's explicit choice if they chose a keycode binding value.
To solve this, create a separate structure, the "devirtualized key combo"
or MetaKeyDevirtCombo, which contains a resolved keycode from the
keysym, and a devirtualized modifier mask. The MetaKeyCombo is now
always a "source" value, and the MetaKeyDevirtCombo is now always what
the user chose.
This also lets us significantly clean up the overlay and ISO key binding
paths.
The reason MetaKeyCombo has a keycode value at all is *not* to store the
devirtualized keycode from the keysym, but instead to allow people that
type in "0x55" into the preference. Everything except the overlay-key
respected this. Make the overlay-key binding respect this.
Since we now directly expose the reverses bindings directly, we
don't have to have this special-case in do_choose_window.
More importantly, if the backwards binding is pressed and has the Shift
key included, this will actually revert it
This doesn't matter for Alt-Tab in gnome-shell, which already replaces
it with a better Alt-Tab replacement, but it does matter for Alt-Esc,
which switches between windows directly.
Commit 1af0033368 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:
"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation
Looping over all keycodes for each layout and level index makes us go
back to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737134
Commit 2f229c3928 removed the code to compute the above-tab
keycode and replaced it with a simple constant from linux/input.h.
We obviously cannot depend on linux headers on non-linux systems,
so provide a fallback definition in that case (which is expected
to work assuming the system is using the Xorg xf86-input-keyboard
driver).
https://bugzilla.gnome.org/show_bug.cgi?id=737135
Clutter events include the layout index codified into modifier_state,
unlike XI2 device events, which means that we need to mask it out so
that we can match successfully.
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.
