Input Grab Systematization
Motivation
Menus from Plasma panels cannot receive keyboard input due to the subpar implementation of grabs; I would like to fix grabs in order to let them receive keyboard input.
The extent of grabs currently is basically "set a flag whenever an xdg-popup requests a grab" which is extremely primitive and prone to bugs; e.g. menus from Plasma panels cannot grab properly due to treatment of Plasma surfaces blocking input before the state of grabs comes into play. It also doesn't implement the protocol properly.
Grab Theory
Some things expect a notion of "grabs" which are a vague group of related concepts that all involve: input becoming temporarily exclusive to a client (or more specifically a surface) regardless of which client/surface would normally receive that input and be marked as focus.
Implementing them can be chunked into two areas:
State Management
There are various Wayland protocols that have the notion of a "grab" with different requirements. They need to be integrated into a single cohesive state in the compositor so that it knows where to send input.
This means balancing the requirements of various protocols, the major ones w/ grabbing stuff:
- xdg_shell#xdg_popup_grab
- input_method_unstable_v1#zwp_input_method_context_v1_grab_keyboard
- input_method_unstable_v2#zwp_input_method_keyboard_grab_v2
XDG popup grabs are specifically related to individual surfaces and require the compositor to sanity check them, while the input method grab isn't associated with any surface and seems to be an at-will thing for the input method.
Input Routing
Input has to be routed to the correct client or surface based on the state. This means either that KWinFT will have to read state from Wrapland and do it itself, or KWinFT will have to feed events into Wrapland and let it do the routing, possibly filtering out events from before internal KWinFT things get at them. (Or an alternative architecure could be done.)
Solution
TODO