| davidedmundson |
| KWin | |
| Frameworks |
The touch related code in the seat interface class has been for no apparent
reason very different to pointer and keyboard code.
This patch makes touch related code more similar and by that allows a client
to receive touch events through multiple interfaces.
Manually and auto tests still pass.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
has been for no apparent reason
From the spec (emphasis mine)
The wl_touch interface represents a touchscreen associated with a seat.
The wl_pointer interface represents one or more input devices,
The wl_keyboard interface represents one or more keyboards associated with a seat.
I assume the rationale being that wl_touch already has multiplicity inside it; mutliple touch screens, just add more touches. Whereas wl_pointer is always just one.
I believe it works like this: A seat has one global pointer, one global keyboard and one global touch "object" each. But clients can bind to them multiple times. That's why there are focus.pointers and focus.keyboards vectors although there is only one global pointer/keyboard.
A different question is what happens on a multi-seat system: when there are several mice or keyboards, the compositor must support splitting them up to multiple seats (but every seat again has only one global keyboard and pointer object). This does not work of course for touch screens, so that's why the specs is reads differently here. But as said this is not directly related to focus.pointers, focus.keyboards or focus.touchs being vectors per seat or not.
Oh, I see what you're saying, I misread, sorry. That does indeed make sense.
Some undocumented fallback code has been removed as well. Platforms not supporting touch are just considered not capable instead.
I don't understand removing this. If I have an app that doesn't understand touch doesn't it make sense to synthesise a pointer?
| src/server/seat_interface_p.h | ||
|---|---|---|
| 147 | touchs -> touches | |
I didn't read the code correctly. Thought it is meant for compositors not supporting touch, but indeed it's meant for clients not supporting it. Hmm, I imagine since most Wayland clients use some sort of GUI library there are not many Wayland native clients not supporting touch. And Xwayland translates touch events. So maybe it would still make sense to remove the code. But I'll add it back for now. This way the change also becomes more narrow.