See 44269e6a1dadb643af3a748c2bcca04ac1ab72eb. The function
add_keycodes_for_keysym() is going to be called more than
once on purpose and we want the keycodes do be appended to
a non-empty GArray.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
We are going to need to call this function more than once to add
all the keycodes to the same GArray. Switch to handle GArrays and
rename the function in order to give a hint that keycodes are going
to be added to the passed GArray.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
We use them in a single place, there is no need to internally keep
track of them. The MetaKeyBindingManager has their resolved key
combo (overlay_resolved_key_combo and locate_pointer_resolved_key_combo)
which is enough. Get the special binding combos from the preference
right away when needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
Commit 48d070dae changed the logic to compare the modifiers mask as a
whole.
Unfortunately, that does not work with all combinations of modifiers, as
some may not be reported when the ISO_Next_Group key is notified.
Revert to the original logic which is to compare against each modifier
mask individually.
Fixes: commit 48d070dae - keybindings: Check for ISO_Next_Group keysym
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4237>
In process_iso_next_group(), we would use try to match mask and keycode
of ISO_Next_Group to tell whether the key combo has been activated.
That works on X11, but not on Wayland with the native backend, because
the keycode does not match.
But we do not need to go all through that burden to match the key combo
we could just use the keysym instead, which would work even when there
is no physical key for ISO_Next_Group.
All we need to do is check whether the symbol is ISO_Next_Group and the
modifier mask matches, which simplifies the code as well.
(Note that we still need to keep the resolved iso_next_group_combo
key combo around because the X11 backend grabs that key combo.)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3883
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4232>
To avoid mostly going through struct fields in macros as we might soon
move those first to a WindowConfiguration & maybe even make the window
struct private with time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4111>
While the events when processing keybindings are quite obviously
key events, the individual structs are all opaque and all public
API is provided by the generic ClutterEvent type. That means that
any handler that uses the passed in event must cast it to
ClutterEvent anyway, so drop the cast to ClutterKeyEvent when
processing key events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4080>
This leads to possibly missed key release events being propagated down to
clients, and in the case of X11 clients, to stuck keys e.g. after switching
workspace with Ctrl+Alt+Left/Right and ending up with a X11 client focused.
Fixes: 11a4d56185 ("keybindings: Send trigger when a key accelerator is deactivated")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3935>
Two new fields: ref_count and removed, are added to MetaKeyHandler, and
it would be freed only if the ref count has reached 0. When handler is
removed from key_handlers GHashTable, key_handler_destroy() would mark
removed as TRUE, and do an unref. handler->removed is checked in
get_keybinding, and binding with handler removed would not be used.
Also in MetaKeyBinding, it now has the ownership of the name field, to
avoid it being freed before logging. Create or copy a binding would
do a ref inc for handler, and free one would unref handler.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1870.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
Locked modifiers should probably not have an effect on keybindings
while toggled. this is most relevant for modifiers that can be
either/both pressed or locked (e.g. Caps Lock key), if used in
keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
Commit 3bfcb6d1 fixed the check for tiling via keybindings, but
ignored a subtle edge case when tiling with the pointer: The
monitor used for tiling is the monitor with the pointer, which
is not necessarily the one that contains the largest part of the
window.
That is, the correct monitor to check against depends on the
context where the function is called. We can either figure
it out automatically via the current window drag, or make it
a parameter.
The latter is clearer, because the callers already decide which
monitor to use for tiling anyway.
Fixes: 3bfcb6d1b9 ("window: Fix portrait orientation check for tiling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3248>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
With the frames client, we do no longer handle events for the
frame window inside Mutter. This means we do not get events
"for free" to handle focus on a just clicked frame window.
This results in a background window not ending up focused if
clicked on its frame.
In order to fix this, make the passive button grab extend to
the frame window if a window has one. This brings back
focus-on-click behavior, while treating windows further as
a unitary surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2727
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
These are done on the backend X11 connection, so it is unclear
what is the interplay through the borrowed global XSetErrorHandler()
that triggers issues for us here.
Anyways, better to be explicit, and use error traps the MetaBackendX11
style, in coherence with the rest of the things happening in that
display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
