[14:11]  * bregma yawns and scratches his chin
[14:13]  * tvoss hands over a coffee to bregma
[14:14] <cnd> morning
[14:14] <cnd> I still have some X patches to get off my plate, need to edit LWN article due to feedback, and more research
[14:19] <bregma> I'm fiishing off reviewing https://code.launchpad.net/~chasedouglas/utouch-grail/remove-v2/+merge/105238
[14:19] <bregma> making sure the entire stack builds and works after
[14:19] <bregma> it requires considerable packaging changes because of the ABI change
[14:19] <bregma> so, lots of waiting for pbuilder then fixing the breakage
[14:21] <cnd> bregma, have you been able to look into Jose's bugs?
[14:21] <cnd> I think he has one or two against geis
[14:21] <cnd> tvoss, dandrader_, standups!
[14:22] <bregma> his bug is that the gesture name attribute is no longer useful in GEISv2
[14:22] <bregma> which it is not
[14: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 recognizer
[14:22] <dandrader_> i.e. what geis events to expect from it
[14:23] <bregma> I will follow up to Jose's bug with a siggestion on how to do it right
[14:24] <tvoss> looking into development processes and reading things up
[14:41] <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:42] <dandrader_> s/ids 1, 2, 4 and 4/ids 1, 2, 3 and 4
[15:04] <cnd> dandrader_, they are implicitly rejected
[15:05] <cnd> so when you accept a gesture, you should clean up any state for any other gestures you have that have overlapping touches
[15:05] <cnd> but you don't need to tell geis to reject those gestures
[15:13] <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:15] <cnd> dandrader_, perhaps, but I thought geis was written so that it shouldn't do that
[15:15] <cnd> oh, I know what's wrong
[15:15] <cnd> geis removes events from its event queue for explicitly rejected gestures
[15:16] <cnd> it apparently doesn't do it for implicitly rejected gestures
[15:16] <dandrader_> cnd, so, is it a bug?
[15:17] <dandrader_> or should applications be resilient to that?
[15:17] <cnd> I think applications should be resilient anyways, but ideally geis would handle that and remove the gesture events from its internal queue
[15:18] <cnd> it's worth filing a bug report with an importance of low
[15:18] <cnd> and if you want to tackle the bug, by all means do so :)
[15:19] <dandrader_> ok
[16:53] <dandrader> cnd,  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 exist
[16:54] <cnd> dandrader, yes, you shouldn't be explicitly rejecting an overlapping gesture
[16:55] <dandrader> but if I just got an event from one and I don't want it, I can naturally reject it
[16:56] <dandrader> but the problem is that the event I got is bogus, because it refers to an entity that no longer exist. like old news
[16:56] <dandrader> hence the failure
[16:56] <dandrader> anyway, I'll report and fix it
[17:11] <cnd> dandrader, thanks :)
[17:25] <cnd> bregma, I just merged the utouch-grail changes
[17:25] <cnd> if you have the packaging changes handy, please push them up
[17:27] <bregma> will 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] <cnd> I don't see a need
[17:27] <cnd> soname bump != version bump
[17:27] <cnd> we're not changing the api/abi for grail outside of removing deprecated functionality
[17:28] <bregma> right, but that removed deprecated functionality was a major chunk of API and APBI
[17:28] <bregma> it doesn;t matter as far as the packaging is concerned, though
[20:49] <dandrader> oh god.... so geis_touch_id(touch) is different than geis_touch_attr_by_name(touch, GEIS_TOUCH_ATTRIBUTE_ID) !!??
[20:50] <bregma> is it?
[20:50] <dandrader> it is :)
[20:51] <dandrader> one maps a touch in a frame to a touch in the touch set of the gesture event
[20:51] <dandrader> (aka index)
[20:51] <dandrader> the other is the touch id that comes from grail that comes from frame that comes from XInput2
[20:52] <dandrader> by the first "frame" I mean geis gesture frame
[20:52] <dandrader> by the second I mean utouch-frame
[20:52] <bregma> ah, I see the confusion
[20:53] <bregma> I 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 table
[20:53] <bregma> somehow