[Webkit-unassigned] [Bug 10598] JSMouseEvent needs to expose tablet pressure

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=10598





------- Comment #5 from ilmari.heikkinen at gmail.com  2008-01-03 20:06 PDT -------
(In reply to comment #4)
> 1.  I'd use "preciseClientX", instead of "accurate", "float" or "double" would
> even be better, except I think those might get more and more precise over time.
>  We'd probably try to expose as accurate values as the device supported, which
> would be doubles on 64bit.

preciseClientX sounds good to me. The accuracy of the values is a bit
non-issue, as a 45cm wide tablet can be addressed down to individual atoms with
32-bit numbers...

Also on naming, noticed that "type" is already used for the event type, so that
would need to be "toolType" instead.


> 2.  How would one register for these?  Would normal places you would get mouse
> events give you these instead?  Probably not.  Could we implement these in
> webkit and test them using an addEventListener("-webkit-tabletmoved", foo,
> false); scheme?
> 
> 3.  If these aren't part of normal mouse events, what do the names of the
> corresponding tablet registrations look like?  tabletMoved, tabletOver,
> tabletOut, etc?

This is a difficult question, let's see..

Mouse events can be thought of as a subset of tablet events (toolType:
'cursor', deviceIndex: 0, all the rest 0, precise coords = normal coords). But
piggy-backing tablet data on mouse events would bloat the mouse event API. And
likely break things.

Having a single tablet event and doing the rest with mouse* would make it
difficult to handle multi-touch (would have to keep track of device coords and
compare mouse event coords to those to figure out which device triggered it.)
It would be the simplest to implement. 

Implementing tabletover, tabletout, tabletdown, tabletup and tabletmove, and
firing them along with the mouse events wouldn't break things, and would make
application programming easier than having a single tablet event. Tablet events
should be fired before mouse events to make it possible to cancel the following
mouse event. Would go with this.

Need to have tabletenter and tabletleave, too, for "a new device has
left/entered the tablet, deal?" Otherwise, difficult to figure out how many
devices there are on the tablet.


> 4.  If these aren't part of normal mouse events, I think normal mouse events
> would be dispatched on a throttled basis, when tablet events were coming in. 
> Tablets send way more events than normal pointing devices do.

I don't know. A tablet does trigger regular mouse events already, do they need
further throttling? I wouldn't throw away input events, if at all possible.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.