[04:25] Hi there! [04:26] just installed utouch, how to activate it? === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [14:17] echo... cho... ho... o... [14:19] howdy [14:19] 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] dandrader, bregma: standups :) [14:20] Studying how mouse events propagates in nux, etc. Started working on the propagation of gesture events in nux. [14:20] good morning [14:22] 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:22] Launchpad bug 803408 in utouch-geis "Subscribing with an empty list of devices subscribes all events" [Low,Triaged] https://launchpad.net/bugs/803408 [14:25] dandrader, btw, is bug 901692 what you were asking about yesterday? [14:25] Launchpad bug 901692 in utouch-geis (Ubuntu) "Need a per-subscription callback context parameter" [Wishlist,Triaged] https://launchpad.net/bugs/901692 [14:27] cnd, looks like it [14:28] bregma, have you had any thoughts on how to resolve that? [14:31] although I'm not sure yet how much (if at all) that would help me with the gestures delivery in nux [14:39] re: 901692, we recently added geis_subscription_[gs]et_configuration(), which makes adding subscription-sprecific context parameters a little simpler [14:39] I'd have to trace through the call sequence to see why I though there would be a complication [14:51] bregma, if that interface will work, please update the bug and mark it as fix released [14:54] there's more to it than just the interface [14:55] there needs to be a way to link a subscription with a gesture [14:55] there still remains code to be written to get the whole thing working [15:00] ok === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch [17:53] bregma, what are your plans for utouch-geis releases and srus in the near future? [18:08] 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:08] Launchpad bug 997630 in utouch-geis (Ubuntu) "evince and eog broken on remote sessions (X, NX, x2go and VNC)" [High,In progress] https://launchpad.net/bugs/997630 [18:09] we should probably do a geis release into quantal by early June === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [22:16] 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] what do you think? do we need more than this? [22:16] dandrader, who/what/how is gesture accept done? [22:17] s/what/where/ :) [22:17] 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] ok [22:17] yes, that sounds right [22:17] GestureEvent class has Accept() and Reject() [22:17] cool [22:17] sounds like what I proposed for utouch-qml [22:18] dandrader, you might have issues with different nux elements subscribing to different gestures [22:18] like 4 touch tap vs 3 touch drag [22:18] how will you reconcile that? [22:18] ensuring that the 4 touch tap takes precedence? [22:19] I'm assuming that nux is basically a scene graph like qml is [22:19] my utouch-qml spec has a mechanism for handling that [22:19] in case you need ideas [22:20] hmm, is it a document or source code? or both? [22:20] document [22:20] one sec [22:21] https://docs.google.com/a/canonical.com/document/d/1B4U7QQS2UtUrhg2dI10GjNFp5I_z9Am0cibQQ7FEWpo/edit [22:21] see the linked algorithm [22:22] utouch-qml is meant to be somewhat generic [22:22] if you there are use cases that it has that nux doesn't, we may be able to pare the algorithm down [22:24] 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] 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] dandrader, make sure you have it worked out how four tap and three drag will coexist [22:27] i.e., three drag will always fire first [22:28] 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] shouldn't "construction finished" handle that? [22:29] dandrader, yes, if the end "client" sees all the gestures [22:29] if one nux element sees the three drag and a different element sees the four tap [22:29] and the three drag element doesn't know about the four tap [22:30] it may become confused or accept the gesture erroneously [22:30] but nux::WindowCompositor will know that [22:30] as he's the one doing the delivery of events [22:31] ok [22:31] sounds fine [22:31] but thanks for bringing up all those cases. I remember then :) [22:31] I just want to make sure you've thought of that :) [22:32] s/remember/didn't remember [22:32] was still thinking mostly in the atomic mode [22:32] well, gotta go. see you tomorrow