[14:14] <cnd> morning all
[14:14] <cnd> bregma, dandrader: standups :)
[14:14] <dandrader> Fixing tap handling in the unity patch that uses the upcoming nux with integrated geisv2.
[14:14] <cnd> I'm mostly continuing research
[14:14] <bregma> *gulp* no changes
[14:15] <cnd> bregma, do you think you'll get to the MP today?
[14:16] <dandrader> I'm coming to the realization that using only Touch gesture classes is the way to go, at least for Unity.
[14:16] <dandrader> specially when dealing with taps
[14:16] <cnd> dandrader, huh?
[14:16] <cnd> why?
[14:16] <bregma> cnd, I hop to try to get to them, they have a higher priority for me today
[14:16] <cnd> ok
[14:17] <dandrader> cnd,  The tap gesture class is super weird, as it sends only a single update and nothing else. that breaks my logic that assumes gestures have a begin, zero or more updates and a an end
[14:18] <cnd> dandrader, you can change that with a geis option
[14:19] <cnd> GEIS_INIT_SEND_TENTATIVE_EVENTS
[14:19] <cnd> it changes the semantics of every gesture you get though
[14:19] <dandrader> and it's super trivial to check if you have a drag a tap etc from a touch gesture
[14:19] <dandrader> and using touch events the client can better reject and accept candidates
[14:20] <cnd> dandrader, but then you're reimplementing grail inside of unity :)
[14:21] <dandrader> cnd, some 30 lines of code from it
[14:21] <dandrader> the "if X is beyond FOO threshold"
[14:21] <dandrader> part
[14:22] <cnd> dandrader, it sounds like you really just want the tentative events
[14:22] <cnd> it essentially gives you the "touch" semantics
[14:22] <cnd> as in, you get all the events from the initial touch to each touch end
[14:22] <cnd> even for a tap
[14:23] <cnd> but it still uses grail for threshold checking, so you aren't bothered with gestures that don't match your subscriptions
[14:26] <dandrader> that might be the case, yes
[14:27] <dandrader> and that single tap gesture update is also broken as it has IsConstructionFinished == false and you never get an update saying that its construction has finished
[14:29] <cnd> dandrader, ahh, that sounds like a bug :)
[14:29] <cnd> dandrader, please try out the tentative events to see if it fits your needs
[14:33] <cnd> if not, we need to know about it
[14:33] <dandrader> cnd, sure. although I'm not sure how much work it will spare me
[14:33] <cnd> dandrader, it's more about determining where utouch may have issues
[14:34] <cnd> it *should* be providing this functionality
[14:34] <cnd> and it *should* save you work
[14:34] <cnd> if not, then that's a problem :)
[14:34] <dandrader> cnd, window manipulation (with 3 fingers) in unity  for instance
[14:34] <dandrader> you need a touch gesture to show the grab handles ASAP
[14:35] <cnd> dandrader, no, you can do a drag with 0 thresholds
[14:35] <cnd> touch gestures were a hack we threw in
[14:35] <dandrader> then you would need a grab and a pinch subscription
[14:35] <cnd> yeah
[14:35] <dandrader> but the touch gesture already gives you drag and pinch info
[14:36] <cnd> but that's just using the "hack" of touch gestures
[14:36] <dandrader> and with window manipulation there's no need to even bother with threshold checks for drags. you just move the window whenever the touch gesture moves
[14:37] <cnd> dandrader, the second issue with just using touch gestures is that you have to do your own pinch checking
[14:37] <cnd> rather than letting utouch tell you when a pinch has occurred
[14:37] <cnd> but admittedly, that isn't a lot of code
[14:37] <dandrader> cnd,  I mean, a geis gesture event already gives you a wealth of info. all the deltas etc you might want. the only missing bit is the "if X > THRESHOLD" part. but that really trivial
[14:38] <dandrader> and it's more convenient to do such checks in your code than to reach for that plain C api (i.e. less readable) to set the thresholds you want
[14:38] <cnd> dandrader, yes, it's the more trivial part of it all, but it is still relying on a code path that is essentially deprecated
[14:39] <cnd> touch gestures are equivalent to drag gestures with a threshold of 0
[14:39] <cnd> we couldn't implement thresholds way back when we had to hack in touch gestures
[14:40] <cnd> at this point, we shouldn't be using touch gestures because there is a better abstraction
[14:40] <dandrader> cnd, btw, current unity code already does its own pinch checking :)
[14:40] <cnd> and where thresholds are not 0, touch gestures are the wrong choice altogether
[14:40] <dandrader>    if (data->radius > 1.25)
[14:40] <dandrader>   {
[14:40] <dandrader>     _pinch_window->maximize(MAXIMIZE_STATE);
[14:40] <dandrader>     EndDrag();
[14:40] <dandrader>   }
[14:40] <dandrader>   else if (data->radius < 0.8)
[14:40] <dandrader>   {
[14:40] <dandrader>     _pinch_window->maximize(0);
[14:40] <dandrader>     EndDrag();
[14:40] <dandrader>   }
[14:41] <dandrader> cnd,  how intuitive and straightforward is that snippet?
[14:41] <cnd> dandrader, yes, but that's because a pinch for this particular use case occurs through the same gesture as the drag with 0 threshold
[14:41] <cnd> imagine you didn't have drag to move the window
[14:41] <cnd> you just had pinch to maximize/unmaximize
[14:42] <cnd> there's no justification for using a touch gesture, you should be telling grail to listen for a pinch
[14:42] <cnd> and setting the threshold to 0.8
[14:42] <cnd> that way grail automatically rejects any touch motion that doesn't meet such a threshold
[15:16] <dandrader> cnd,  about tentative events. So a successful gesture would have: tentative_begin, tentative_update, update and end whereas a failed one would be tentative_begin, tentative_update and tentative_end?
[15:36] <cnd> you won't get gesture events for failed gestures
[15:36] <cnd> that's part of the purpose of grail thresholds
[15:45] <cnd> tentative is somewhat poorly named
[15:45] <cnd> it's more that you get events that are known to be a part of a subscribed gesture, but you get all the events, including those before the gesture is recognized
[15:50] <cnd> so the first events until a gesture is recognized *were* tentative events, and that's what you're asking for with the geis option
[16:18] <dandrader> cnd, does it make sense to have a gesture_end with is_construction_finished=false?
[16:18] <cnd> dandrader, no
[16:18] <cnd> where are you seeing that?
[16:19] <dandrader> in geis
[16:19] <dandrader> if you do a quick tap
[16:19] <dandrader> I guess it's because the gesture ends before composition_time is passed
[16:19] <cnd> could be
[16:53] <dandrader> hmm... using GEIS_INIT_SEND_TENTATIVE_EVENTS leads to a crash in geis when I do a tap :(
[16:55] <dandrader> maybe the simplest way would be for my GeisAdapter to generate a begin and an end event out of that single tap update event...
[20:44] <cnd> whoa, it's actually cypress chips powering the macbook trackpads
[20:44] <cnd> the bcm597{4,6} chips seem to be just the data transport
[20:49] <cnd> hmm... the cypress chip is merely a programmable SoC
[20:49] <cnd> so Apple and/or Cypress have added touch sensing capabilities on top
[20:51] <cnd> interesting...