=== MacSlow is now known as MacSlow|lunch
[12:08] <bregma> hey lads, I won't be around for standup today, I have to run an errand up Renfrew way
[12:09] <bregma> if anyone sees dandrader, tell him I need the two latest merge proposals reviewed ASAP
[12:21] <tvoss> bregma, ack
=== MacSlow|lunch is now known as MacSlow
[13:09] <dandrader> bregma, is there a coding style that utouch-geis follows for C++ code?
[14:14] <tvoss> finishing hd recovery, preparations for sprint
[14:15] <tvoss> dandrader, standups :)
[14:16] <dandrader> reviewing https://code.launchpad.net/~bregma/utouch-geis/gtest-refactor/+merge/103738 and learning about some fancy C++ constructs along the way (like std::bind)
[14:22] <tvoss> dandrader, pointers to member functions are so much fun :)
[14:22] <tvoss> therefore mem_fun
[14:22] <xerent> getting ready to test my multi-touch controller with ubuntu. are generic HID multi-touch digitizer drivers included in 12.04 LTS? will they load automatically when the USB device is detected and the interface/report descriptors parsed? should I do anything in preparation or just slap the device on the USB bus?
[14:23] <xerent> lots of stupid questions, bear with me ;)
[14:25] <dandrader> xerent, I think cnd would be the guy to answer those questions but he's not around today (even though still logged on).
[14:28] <xerent> i'll stay idle, don't worry :)
=== dandrader is now known as dandrader|afk
[16:09] <bregma> dandrader|afk, MP requested changes done, could be please give another review so I can  SRU #987539 (and others) today?
[16:10] <bregma> bug 987539 is a regression from 11.10
[16:10] <ubot5> Launchpad bug 987539 in utouch-geis (Ubuntu Precise) "Grail backend does not populate device X and Y axis attributes" [Medium,In progress] https://launchpad.net/bugs/987539
=== dandrader|afk is now known as dandrader
[16:34] <bregma> thank ye
=== dandrader is now known as dandrader|lunch
[17:08] <bregma> I hate writing SRUs, they make me feel like I'm doing something wrong for some reason
=== dandrader|lunch is now known as dandrader
[18:02] <dandrader> bregma, that's probably part of the idea behind the SRU process :)
[18:03] <bregma> I guess it's like dating:  if you don;t feel humiliated, you're doing it wrong
[19:26] <dandrader> bregma, let's suppose I have two subscriptions in a utouch-geis client that's _not_ using atomic gestures: a 3-touches Touch and a 4-touches Drag. Then I get a GestureBegin for a 3-touches touch. How do I know that there's not a 4-fingers drag coming up?
[19:27] <dandrader> because if I accept that 3-fingers touch straight away I won't ever receive the 4-fingers drag, right?
[19:29] <bregma> at this point, I'm just not sure any more
[19:30] <bregma> I think we need Chase to give us an overview of non-atomic gestures next week
[19:30] <dandrader> yep
[19:31] <dandrader> I recall that at least in GRAIL api there's a property telling you whether all possible gesture combinations have already been presented
[19:32] <dandrader> so that, in this case, you would know whether it's safe to accept the 3-touches' Touch as there's not a possibility for a 4 touches' drag anymore containing the same touch points
[19:33] <dandrader> UGSlicePropertyConstructionFinished
[19:33] <dandrader> bregma, is that property or concept exposed in geis?
[19:34] <bregma> nope
[19:36] <dandrader> hmmm, I think we need such thing in Geis. I just hit a wall in the unity gestures implementation using non-atomic rules. Unless I implement a kind of timeout mechanism on unity side, which wouldn't be nice
[19:38] <bregma> it would need to be transformed into an event (so, from level-triggered to edge-triggered)