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