wl_tablet draft v2

[Bill Spitzak]

On 07/17/2014 12:58 PM, Lyude wrote:
> On Thu, 2014-07-17 at 11:48 -0700, Bill Spitzak wrote:

> A button count could definitely be added. But for clarification, are you
> suggesting this somehow replace the frame event we have right now?

What I am trying to fix is the need for all the code modules to keep a 
state map for all the buttons and do tests to generate up/down events in 
order to send exact matching pairs to the next module. This actually 
does not make it any easier on the next module, as it is almost always 
has to do exactly the same thing, because internal code paths can't 
guarantee pairs any other way. It can also make debugging hard as each 
module will generate events that will hide errors in the events produced 
by earlier modules.

Sending the entire state map with each event would work, but is ugly. I 
think a count would work: it is a small number, the useful state of "no 
buttons down" is indicated by zero, a one-button state can be indicated 
by one on a down event. And current state could be transmitted by 
sending phony down events (kind of like what you are proposing) that 
don't change the count.

The main purpose is so intermediate levels can blindly pass events 
through, even if they change which client they go to.

>> It seems like each tool should be a different device. Ie the api should
>> support the entry of two different tools, and the pushing of the tip of
>> both of them. The above api does not, because the push event does not
>> indicate which tool.
> I'm not entirely sure what you mean by this; are you talking about using
> two different tablet tools on a single tablet at once? As for having
> each tool separate, I think I've decided on running most of the axis,
> motion, button, etc. events through a tool object instead of from the
> tablet itself, since this would simplify the handling of multiple unique
> tools.

That sounds like the same thing.

My concern was that from the description previously, if the user used 
the pen the client would get "proximity-in pen", then "down". If the 
user used the airbrush they would get "proximity-in airbrush", then 
"down". This means that even if the hardware is capable of the user 
bringing both the pen and airbrush into proximity and then pushing them 
both down, a fake proximity-out would have to be given so that the down 
event was associated with the correct tool. What I was suggesting, but I 
think is what you are saying too, is that the id of the source is not 
the tablet, but a different id for each tool.