Snowcap: Add support for touch input

[Ph4ntomas]

This adds support for touch input for snowcap.

When a touch input is received on a surface, it's converted to an iced touch input event, and sent to the surface widget.

Iced currently ignores position when handling touch inputs. As a workaround, I'm updating the surfaces cursor position when processing input. This isn't ideal because the cursor position and the mouse gets temporarily disconnected, but is safe to do because the last known position is always sent in pointer events. This however prevent mouse_area from firing "Leave" events, because the position will only be updated on the next input (mouse or touch) event, but I felt it was better than missing the release event.

Hopefully, iced-rs/iced#3234 will solve this, and improve touch inputs in general at some point.

---

I'm opening this up for review, but there is a few thing that still need to be done:

• better documentation (example, lua-doc, ...)
• some decision on the improved button & mouse-area. Should they be kept in-tree ? Should they be out of tree ? Not included ? (even tho they are broken for touch control, the toucharea works so the patched version are not mandatory)

The name also somewhat became misleading as this PR no longer only make changes in snowcap, For the full changes:

• touching a window will set the focus to that window.
• MoveSurfaceGrab and ResizeSurfaceGrab (interactive move/resize) can now support touch-based inputs.
• It's possible to start touch-based grab from the config.
• Touch area widget can be used to retrieve finger_id as well as touch related events. This allows for example to start a resize-grab when touching the border of a floating window.

[Ph4ntomas]

Regarding the touch behavior, I'll note that since we do have the data, it could be fixed 'cleanly' (as in without glitches) by copying button and mouse_area implementation from iced and patching it in snowcap.

The behavior would be much cleaner, but I don't want to do that unless I know it's okay, since we would not get new changes if iced behavior changes.

An alternative would be to have a "touch button" and a "touch mouse_area" that would wrap their iced counterpart, and fixup the touch inputs (e.g. by spoofing the cursor position) before forwarding the update call. This would allow to transparently get fixes in button & mouse_area from upstream, while having the correct behavior.

Another alternative would be to handle the touch input fixup in the surface update function. This is less clean than the previous one, because we can't force the touch position to be inside a widget (to take into account the fact that finger are not points), but represent less code to maintain (but it will be easier to forget)

EDIT: Scratch that last part. I don't like it.

I think I'll implement the patched button/mouse out of tree (unless I get the go to merge them here). This could be a "drop-in" replacement until iced gets fixed that pinnacle could add as a dependency and drop whenever, while both maintaining the same "button" and "mouse_area" API (i.e. no changes to protobuf). If we don't want to use them, I can easily patch them in in my own tree.

Either way, I'm putting this back to draft until that's done, since I'll remove the workaround and touch inputs are somewhat useless/weird without that.

[Ph4ntomas]

I think I'll implement the patched button/mouse out of tree (unless I get the go to merge them here). This could be a "drop-in" replacement until iced gets fixed that pinnacle could add as a dependency and drop whenever, while both maintaining the same "button" and "mouse_area" API (i.e. no changes to protobuf). If we don't want to use them, I can easily patch them in in my own tree.

Okay, so I did that but it kinda broke down when I looked at hooking the mouse-area to a grab, since touch grabs need fingers.

Anyway, I'm in the process of implementing a TouchArea (which is a mouse-area-ish that works correctly for touch inputs), but since that's kinda foreign to iced, I've implemented it here.

The patched button & mouse area are still out of tree tho.

[Ph4ntomas]

Touch "bind" are left out of scope on purpose. There are a bunch of stuff I need to think about before implementing them.

I'd also like another type of grab that would make use of the multi-touch capabilities of touch-screen, which should also be kept for later.

[Ph4ntomas]

Okay, I'm dropping the custom widgets.

I had a look at how iced handle this, they are just setting the cursor position on touch inputs using the latest touch. Let's not do anything too fancy and go with that. It might be a good idea to swap the pointer_location member in Surface to a Cursor so we can properly handle touch cancellation instead, my "floating" the cursor, but I'll do that later.