| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| 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:14 |
| cnd | bregma, do you think you'll get to the MP today? | 14:15 |
| 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:16 |
| 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:17 |
| cnd | dandrader, you can change that with a geis option | 14:18 |
| 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:19 |
| cnd | dandrader, but then you're reimplementing grail inside of unity :) | 14:20 |
| dandrader | cnd, some 30 lines of code from it | 14:21 |
| dandrader | the "if X is beyond FOO threshold" | 14:21 |
| dandrader | part | 14:21 |
| 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:22 |
| cnd | but it still uses grail for threshold checking, so you aren't bothered with gestures that don't match your subscriptions | 14:23 |
| dandrader | that might be the case, yes | 14:26 |
| 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:27 |
| 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:29 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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 | 14:42 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:16 |
| cnd | you won't get gesture events for failed gestures | 15:36 |
| cnd | that's part of the purpose of grail thresholds | 15:36 |
| 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:45 |
| 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 | 15:50 |
| 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:18 |
| 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:19 |
| dandrader | hmm... using GEIS_INIT_SEND_TENTATIVE_EVENTS leads to a crash in geis when I do a tap :( | 16:53 |
| 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... | 16:55 |
| === 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 | ||
| 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:44 |
| 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:49 |
| cnd | interesting... | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!