[PATCH wayland-protocols] Add the tablet protocol

[Daniel Stone]

Bill,

On Monday, 16 November 2015, Bill Spitzak <spitzak at gmail.com> wrote:

> There is a need to distinguish proximity-out from exit events. It is quite
> possible to move the stylus so that the focus enters another client without
> doing a proximity-out. Clients are interested in distinguishing these.
>

This is true, hence my suggestion.


> I really feel the best method is to say a "seat" has a keyboard focus and
> a pointer focus, and let the stylus manipulate the pointer focus. Thus the
> client will get enter/exit events as the stylus is moved around above the
> tablet, and proximity in/out when it is moved toward/away from the tablet
> (it may also get a fake proximity-in event on enter).
>

Pointer and tablet/touch are separate. X11 integrated them, and _that_ was
a huge mistake. From our point of view, this is a closed topic.

We've been over it time and time again, we've seen the ways the alternate
model - though it seems attractive at first, which is why we did it for X11
- fails, and we're not going back there.


> I really feel the cursor stuff is a huge mistake. It adds lots of
> complexity for almost no actual gain. Witness how much code you had to add
> to toytoolkit to support it. It adds complexity to clients as the client
> has to pass which tool to subroutines for no reason other than to allow
> them to change the correct cursor. The clients cannot assume the tool has
> the "right" cursor and therefore they are required to have code to change
> it, so this removes no complexity from clients. It is also hugely
> inconsistent with how normal pointer enter events are handled in Wayland.
>

It's not 'no actual gain', it's integral to the model.


> The only argument you had was that the cursor is more likely to be
> correct, so when the proximity-in event happens, the cursor that appears
> has a higher chance of being the same as the one the client sets and there
> will be less blinking. However this can be implemented by the compositor
> without any client api. Just have the compositor remember what cursor was
> used and set that as a guess on the enter event. The client can remain
> completely unaware of whether a cursor is remembered per-tool, or
> per-surface, or per tool*surface, or whatever.
>

The reason the protocol does not do this, is because when the cursor is
different, you go from the other-surface cursor, to the old new-surface
cursor, to the new new-surface cursor, very rapidly. It's ugly, and a
bandaid for clients not responding quickly enough.

This line has been discussed to death, and we won't be pursuing it any
further. I've enjoyed some of your more constructive contributions over the
past year or so, but am sad to see you regress back into suggesting
rewriting the entire protocol - overriding considered discussion made at
the time - because you prefer the superficial aspects of an alternate
approach. Please don't make a habit of this.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151116/9ca899ab/attachment.html>