/srv/irclogs.ubuntu.com/2012/05/18/#ubuntu-touch.txt

=== gustavold1 is now known as gustavold
* bregma yawns and scratches his chin14:11
* tvoss hands over a coffee to bregma14:13
cndmorning14:14
cndI still have some X patches to get off my plate, need to edit LWN article due to feedback, and more research14:14
bregmaI'm fiishing off reviewing https://code.launchpad.net/~chasedouglas/utouch-grail/remove-v2/+merge/10523814:19
bregmamaking sure the entire stack builds and works after14:19
bregmait requires considerable packaging changes because of the ABI change14:19
bregmaso, lots of waiting for pbuilder then fixing the breakage14:19
cndbregma, have you been able to look into Jose's bugs?14:21
cndI think he has one or two against geis14:21
cndtvoss, dandrader_, standups!14:21
bregmahis bug is that the gesture name attribute is no longer useful in GEISv214:22
bregmawhich it is not14:22
dandrader_I'm poking utouch-geis in a test with x11 mocks to understand exactly how it works and what it does when using the regular recognizer14:22
dandrader_i.e. what geis events to expect from it14:22
bregmaI will follow up to Jose's bug with a siggestion on how to do it right14:23
tvosslooking into development processes and reading things up14:24
dandrader_cnd, Imagine I subscribed to 2-touches Touch gestures and that 4 touch points (ids 1, 2, 4 and 4) started moving. I get 6 different "Gesture Begin" geis events, one for each combination of two touch points. I accept the pairs (1,2) and (3,4). Should the remaining four pairs automatically vanish or should I explicitly reject them?14:41
dandrader_s/ids 1, 2, 4 and 4/ids 1, 2, 3 and 414:42
=== mhall119_ is now known as mhall119
cnddandrader_, they are implicitly rejected15:04
cndso when you accept a gesture, you should clean up any state for any other gestures you have that have overlapping touches15:05
cndbut you don't need to tell geis to reject those gestures15:05
dandrader_cnd, well, I do get "begin" and "update" events from (1,3) after (1,2) has been accepted. Is it because those events were already created and queued up by the time I accepted (1,2)?15:13
cnddandrader_, perhaps, but I thought geis was written so that it shouldn't do that15:15
cndoh, I know what's wrong15:15
cndgeis removes events from its event queue for explicitly rejected gestures15:15
cndit apparently doesn't do it for implicitly rejected gestures15:16
dandrader_cnd, so, is it a bug?15:16
dandrader_or should applications be resilient to that?15:17
cndI think applications should be resilient anyways, but ideally geis would handle that and remove the gesture events from its internal queue15:17
cndit's worth filing a bug report with an importance of low15:18
cndand if you want to tackle the bug, by all means do so :)15:18
dandrader_ok15:19
=== dandrader_ is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
dandradercnd,  there's definitely a real bug here, because if you try to explicitly reject one of those gestures that overlap the accepted one in geis the call will fail because in the grail backend those gestures no longer exist16:53
cnddandrader, yes, you shouldn't be explicitly rejecting an overlapping gesture16:54
dandraderbut if I just got an event from one and I don't want it, I can naturally reject it16:55
dandraderbut the problem is that the event I got is bogus, because it refers to an entity that no longer exist. like old news16:56
dandraderhence the failure16:56
dandraderanyway, I'll report and fix it16:56
cnddandrader, thanks :)17:11
cndbregma, I just merged the utouch-grail changes17:25
cndif you have the packaging changes handy, please push them up17:25
bregmawill do... is grail going to be bumped to 4.0 to reflect the major ABI change, or is there some other versioning scheme at work?17:27
cndI don't see a need17:27
cndsoname bump != version bump17:27
cndwe're not changing the api/abi for grail outside of removing deprecated functionality17:27
bregmaright, but that removed deprecated functionality was a major chunk of API and APBI17:28
bregmait doesn;t matter as far as the packaging is concerned, though17:28
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
dandraderoh god.... so geis_touch_id(touch) is different than geis_touch_attr_by_name(touch, GEIS_TOUCH_ATTRIBUTE_ID) !!??20:49
bregmais it?20:50
dandraderit is :)20:50
dandraderone maps a touch in a frame to a touch in the touch set of the gesture event20:51
dandrader(aka index)20:51
dandraderthe other is the touch id that comes from grail that comes from frame that comes from XInput220:51
dandraderby the first "frame" I mean geis gesture frame20:52
dandraderby the second I mean utouch-frame20:52
bregmaah, I see the confusion20:52
bregmaI would expect all the touch_id values in a touch to be the same, and a geis frame touch should be an index into the touch table20:53
bregmasomehow20:53
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!