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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
