The wlr-virtual-keyboard-v1 protocol fails to make keyboard creation
atomic. There is nothing a client can do with a virtual keyboard that
has no keymap except for destroy it, so we can completely ignore them
until a keymap is set.
This fixes a regression with fcitx caused by river sending the null
keymap of a new virtual keyboard to fcitx.
There is not any pointer emulation for tablet tool input. This means
that only clients implementing the tablet-v2 protocol will be able to
process tablet tool input.
Tablet pad support is TODO
The protocol states that we must send enter and leave to all text input
objects if the client has created multiple.
Only one text input is allowed to be activated by the client per seat
however.
Now with 50% less pointer warping!
The new implementation requires the user to move the cursor into the
constraint region before the constraint is activated in order to keep
behavior more predictable.
This implementation as it stands is incomplete/buggy and will make
updating to wlr_scene more complex.
It will be reimplemented after updating to wlr_scene is complete.
- The lifetimes of the Keyboard and Switch structs are now directly
tied to the corresponding InputDevice, which has become a field of
those structs.
- Seat capabilities are now properly updated on removing a keyboard.
These changes align with input device refactoring in upstream wlroots
which will make updating to easier 0.16.0.
Currently if a view is mapped while some other view is fullscreen, it
will not be added to the focus stack, which means that if the fullscreen
view is then closed the view which was not added to the focus stack will
not be focused.
To fix this, always add views to the focus stack on map.
If the current Cursor.maybeResetState() function is called while in
passthrough mode, it will send a pointer motion event. This is
unnecessary as we have already sent the same pointer motion event at
least once.
Also refactor the code slightly and improve naming.
Now that we properly handle state changes during cursor operations,
blocking these commands if the target view is the target of a cursor
operation is unnecessary complexity. It is also inconsistent as we
don't block changing the tags of the view.
A client is free to change its mind and request a different
size/anchor/etc after recieving the initial configure but before
attaching and committing the first buffer. This means that we should
respond to such a situation with a new configure.
mako has been observed doing this in the wild for example.
