[04:25] <WebVisitor-3> Hi there!
[04:26] <WebVisitor-3> just installed utouch, how to activate it?
[14:17] <bregma> echo... cho... ho... o...
[14:19] <cnd> howdy
[14:19] <cnd> I have to fix up a couple X patches, and then I'm going to be doing research and actually noting down findings
[14:19] <cnd> dandrader, bregma: standups :)
[14:20] <dandrader> Studying how mouse events propagates in nux, etc. Started working on the propagation of gesture events in nux.
[14:20] <dandrader> good morning
[14:22] <bregma> I'm (a) fixing bug #803408 'cos it's a simple fix (and a complex test case) and trying to track down that segfault in gesture-accept
[14:25] <cnd> dandrader, btw, is bug 901692 what you were asking about yesterday?
[14:27] <dandrader> cnd, looks like it
[14:28] <cnd> bregma, have you had any thoughts on how to resolve that?
[14:31] <dandrader> although I'm not sure yet how much (if at all) that would help me with the gestures delivery in nux
[14:39] <bregma> re: 901692, we recently added geis_subscription_[gs]et_configuration(), which makes adding subscription-sprecific context parameters a little simpler
[14:39] <bregma> I'd have to trace through the call sequence to see why I though there would be a complication
[14:51] <cnd> bregma, if that interface will work, please update the bug and mark it as fix released
[14:54] <bregma> there's more to it than just the interface
[14:55] <bregma> there needs to be a way to link a subscription with a gesture
[14:55] <bregma> there still remains code to be written to get the whole thing working
[15:00] <cnd> ok
[17:53] <cnd> bregma, what are your plans for utouch-geis releases and srus in the near future?
[18:08] <bregma> I have no concrete plans for a release in the near future, but bug #997630  should probably be SRUd, it's a usability regression
[18:09] <bregma> we should probably do a geis release into quantal by early June
[22:16] <dandrader> cnd, I'm thinking about a simple gestures delivery mechanism for nux, at least for a first iteration: 1- gesture comes in. 2- find nux::InputArea that is hit by that gesture and that has a subscription matching it. If found, deliver events of this gesture  to that are. if not, reject gesture.
[22:16] <dandrader> what do you think? do we need more than this?
[22:16] <cnd> dandrader, who/what/how is gesture accept done?
[22:17] <cnd> s/what/where/ :)
[22:17] <dandrader> the InputArea that get hit will receive the events for that gesture. so it can accept or reject it on its own accord
[22:17] <cnd> ok
[22:17] <cnd> yes, that sounds right
[22:17] <dandrader> GestureEvent class has Accept() and Reject()
[22:17] <dandrader> cool
[22:17] <cnd> sounds like what I proposed for utouch-qml
[22:18] <cnd> dandrader, you might have issues with different nux elements subscribing to different gestures
[22:18] <cnd> like 4 touch tap vs 3 touch drag
[22:18] <cnd> how will you reconcile that?
[22:18] <cnd> ensuring that the 4 touch tap takes precedence?
[22:19] <cnd> I'm assuming that nux is basically a scene graph like qml is
[22:19] <cnd> my utouch-qml spec has a mechanism for handling that
[22:19] <cnd> in case you need ideas
[22:20] <dandrader> hmm, is it a document or source code? or both?
[22:20] <cnd> document
[22:20] <cnd> one sec
[22:21] <cnd> https://docs.google.com/a/canonical.com/document/d/1B4U7QQS2UtUrhg2dI10GjNFp5I_z9Am0cibQQ7FEWpo/edit
[22:21] <cnd> see the linked algorithm
[22:22] <cnd> utouch-qml is meant to be somewhat generic
[22:22] <cnd> if you there are use cases that it has that nux doesn't, we may be able to pare the algorithm down
[22:24] <dandrader> I'm considering that if the target nux::InputArea rejects the gesture, that gesture gets rejected for good (geis_reject_gesture gets called) and won't be offered to other nux::InputAreas
[22:26] <cnd> dandrader, if you can figure out how to meet all the requirements for the unity gesture spec with such a design, then that's cool :)
[22:27] <cnd> dandrader, make sure you have it worked out how four tap and three drag will coexist
[22:27] <cnd> i.e., three drag will always fire first
[22:28] <cnd> but if you deliver it to a nux window and it accepts before the four tap comes in for the desktop, then what do you do?
[22:28] <dandrader> shouldn't "construction finished" handle that?
[22:29] <cnd> dandrader, yes, if the end "client" sees all the gestures
[22:29] <cnd> if one nux element sees the three drag and a different element sees the four tap
[22:29] <cnd> and the three drag element doesn't know about the four tap
[22:30] <cnd> it may become confused or accept the gesture erroneously
[22:30] <dandrader> but nux::WindowCompositor will know that
[22:30] <dandrader> as he's the one doing the  delivery of events
[22:31] <cnd> ok
[22:31] <cnd> sounds fine
[22:31] <dandrader> but thanks for bringing up all those cases. I remember then :)
[22:31] <cnd> I just want to make sure you've thought of that :)
[22:32] <dandrader> s/remember/didn't remember
[22:32] <dandrader> was still thinking mostly in the atomic mode
[22:32] <dandrader> well, gotta go. see you tomorrow