[14:16] <cnd> good morning
[14:16] <cnd> bregma, dandrader: standups :)
[14:16] <cnd> I'm in the middle of investigations, not much new
[14:16] <bregma> just finishing off the code reviews
[14:16] <bregma> uh, merge proposal reviews
[14:18] <dandrader> back to work on the gestures delivery logic. Noticed that there's a situation that's not being considered there. i.e. gestures with the very same set of touches are not in conflict with each other as they just present complementary info on the same physical gesture (e.g. a touch and a drag gesture)
[16:30] <dandrader> cnd, ping
[16:38] <cnd> dandrader, pong
[16:38] <dandrader> I'm cornered here. geis_v1 implementation of unity gestures is as follows:
[16:39] <dandrader>  - touch gestures used to show and hide the grab handles
[16:39] <dandrader>  - drag gestures to move the window
[16:39] <dandrader>  - pinch gestures to maximize and restore the window
[16:39] <dandrader> and those gestures can come in parallel
[16:39] <dandrader> so you can get both touch and drag
[16:40] <cnd> yeah
[16:40] <dandrader> in geis_v2 implementation I made one subscription for each of those gesture classes
[16:41] <dandrader> so, when I start moving 3 fingers
[16:41] <cnd> ahh, what you need to do is make one subscription with multiple filters
[16:41] <cnd> IIRC
[16:41] <dandrader> problem is that it seems I cannot make an OR for gesture classes
[16:41] <dandrader> in a filter
[16:41] <cnd> hmm
[16:42] <cnd> bregma^^?
[16:42] <cnd> I thought that was possible
[16:42] <cnd> you can have multiple filters on one subscription
[16:42] <cnd> so one filter for three touch drag
[16:42] <cnd> one filter for three touch pinch
[16:44] <dandrader> but the filters on a subscription will be "ANDed" together
[16:44] <cnd> dandrader, I believe filters are ORed, terms are ANDed
[16:45]  * dandrader checks
[16:46] <dandrader>  * Thye effect of filters are ANDed together so that, for example, a
[16:46] <dandrader>  * subscription that has a filter for 3-finger gestures and drag gestures will
[16:46] <dandrader>  * produce events only for 3-finger drag gestures.
[16:46] <dandrader> cnd,  at least that's what the documentation says
[16:47] <cnd> hmm... what is it that is ORed...
[16:47] <dandrader> subscriptions :)
[16:47] <cnd> I'm pretty sure there was something below that though
[16:49] <cnd> dandrader, I'm suspicious that that comment is incorrect
[16:49] <dandrader> I'm checking the implementation to see if that's the case...
[16:58] <bregma> sorry guys, meetigs are eating my soul
[16:58] <bregma> terms on a filter should be ANDed, filters on a subscription should be ORed
[16:59] <bregma> if it's not doing that, I messed up, and I know I confused myself at some point
[17:02] <dandrader> bregma,  ahhh, cool. so there's a bug in the documentation after all
[17:02] <bregma> hopefully
[18:43] <dandrader> bregma, do you want a merge proposal for the patch that fixes geis_subscription_add_filter documentation?
[18:44] <bregma> I personally would consider such a change "as obvious", so I don;t think a merge request is necessary
[18:44] <dandrader> bregma, ok
[18:45] <dandrader> pushed
[18:45] <dandrader> cnd, one subscription with multiple filters behaves exactly the same as one subscription per filter
[18:46] <dandrader> which is what I'm doing
[18:46] <dandrader> so that doesn't help
[18:46] <cnd> hmm... really?
[18:46] <cnd> dandrader, oh, maybe we're thinking two different things
[18:46] <dandrader> probably
[18:46] <dandrader> the problem is
[18:46] <cnd> with multiple filters you'll still just get one set of events
[18:46] <cnd> but the events will be recognized as one or more of the subscription types
[18:46] <dandrader> (again with the window manipulation example in unity)
[18:47] <cnd> and will fire when any of the filters matches
[18:47] <dandrader> as soon as you accept one gesture, the others vanish
[18:47] <dandrader> so if I accept the touch, drag vanishes
[18:47] <dandrader> and vice-versa
[18:47] <dandrader> and then a pinch will never come as well
[18:47] <dandrader> if I have a touch or a drag accepted
[18:49] <cnd> dandrader, if you use multiple filters, are you getting multiple event streams for each filter?
[18:49] <cnd> or just one event stream
[18:50] <dandrader> cnd, let me send you a typical output of sliding 3 fingers: http://paste.ubuntu.com/1039514/
[18:50] <dandrader> notice the ACCEPT part
[18:50] <cnd> hmm... that's not what I expect to happen
[18:50] <cnd> I expect there to be one gesture, that has multiple classes
[18:51] <cnd> first it starts as just a touch class
[18:51] <cnd> and then it becomes a drag class too
[18:53] <cnd> I'm not exactly sure what the best way to handle this is, if geis is broken, or if it just doesn't cater to this use case...
[18:53] <cnd> bregma, what are your thoughts ^^?
[18:53] <dandrader> subscription ( filter (3 drag) filter (3 touch) ) ==  subscription ( filter (3 drag)  subscription ( filter (3 touch) )
[18:53] <dandrader> correcting:
[18:53] <dandrader> subscription ( filter (3 drag) filter (3 touch) ) ==  subscription ( filter (3 drag) )  subscription ( filter (3 touch) )
[18:53] <cnd> yeah
[18:53] <cnd> which is not how it should be, imo
[18:54] <cnd> otherwise, there's no point in having filters vs subscriptions
[18:54] <dandrader> well, you could see subscriptions just as a container to group filters together
[18:55] <cnd> yeah, but then it's just an added layer of abstraction
[18:55] <dandrader> sure, not that this is all that useful indeed :)
[18:56] <cnd> let's wait to get some feedback from bregma
[18:56] <cnd> then we can try to figure out what to do about it
[19:00] <bregma> sorry guys, OTP, reading the backscroll....
[19:01] <cnd> bregma, np :)
[19:04] <bregma> dandrader, are you saying you get the same output when you have a single subscription with a single filter with terms (touch EQ 3) and (class EQ DRAG) as you do with two separate subscriptions, one for each filter term?
[19:06] <bregma> one subscrption with two filters, each with one term, will definitely behave like two subscriptions each with one filter each with one term
[19:07] <bregma> because filters are ORed
[19:07] <bregma> but one subscription with one filter with two terms should behave differently form that
[19:07] <cnd> bregma, I thought one geis subscription == one grail subscription
[19:08] <bregma> no
[19:08] <cnd> if there are multiple filters on a geis subscription, then they are composited for the grail subscription
[19:08] <bregma> it's more like one filter == one grail sibscription
[19:08] <cnd> hmm
[19:08] <dandrader> bregma, no. I mean sub(filter(class=drag, touches=3)) + sub(filter(class=touch, touches=3)) behaves the same as sub((filter(class=drag, touches=3),filter(class=touch, touches=3))
[19:09] <bregma> yes
[19:10] <dandrader> bregma, so what do I do in geis API to get gesture events with classes (touch OR drag)
[19:10] <dandrader> ?
[19:11] <bregma> that what those subscriptions should be giving you
[19:11] <bregma> hmm, I think I see the problem
[19:11] <cnd> what we have now is touch XOR drag
[19:11] <cnd> we don't seem to have touch OR drag
[19:12] <bregma> the problem lies in the interaction between subscriptions and accept/reject
[19:12] <cnd> yeah
[19:14] <bregma> grail subscription don;t really let you do ORing, as I recall
[19:14] <cnd> they do
[19:15] <cnd> you can subscribe to a list of types
[19:15] <cnd> and then you can set the thresholds for each type
[19:16] <bregma> right, grail uses a bitmap for subscriptions
[19:17] <cnd> bregma, so are we talking a large change to geis to make this functionality possible?
[19:19] <bregma> um, looking at the code it looks like repreated class terms are ORed
[19:19] <dandrader> the solution is see for the moment if to not specify any class in the filters
[19:19] <dandrader> s/if to/is to
[19:20] <cnd> bregma, I think the bigger issue is that geis splits grail events into separate gesture streams for each gesture class
[19:20] <cnd> rather than having one stream with multiple classes
[19:21] <bregma> geis doesn't split gestures
[19:22] <bregma> it looks like of you add two class terms to a filter it will OR them and do exactlt what you;re asking
[19:23] <dandrader> just like magic
[19:24]  * dandrader tries out
[19:26] <dandrader> bregma, yes, you're right!
[19:27] <bregma> what a fortunate bug
[19:27] <dandrader> lol
[19:27] <bregma> er, feature
[19:27] <dandrader> man, that's a complex API
[19:28] <bregma> ANDing two classes makes no sense, because then you will have no results
[19:28] <bregma> but logically it makes sense because it's symmetric
[19:29] <bregma> perhaps the best solution for this is to document it well
[19:29] <cnd> heh
[19:29] <cnd> yay
[19:29] <cnd> disaster averted
[19:35] <dandrader> so in the end  having the filter concept is superfluous as you can achieve the same results with just adding terms directly to a subscription
[19:35] <dandrader> s/can/could
[19:41] <cnd> sounds right
[21:54] <Jonii_> Hi, how much of a work it would be to implement one touch gesture?
[21:55] <Jonii_> I mean, say I' running ubuntu 12.04, and I just want to see this gesture to happen on my own computer?
[22:16] <cnd> Jonii_, for a touchscreen?
[22:27] <Jonii_> touchpad
[22:38] <cnd> Jonii_, you can't listen to one-touch gestures from a touchpad
[22:39] <cnd> because one-touch motion controls the cursor
[23:37] <Jonii_> cnd: i was thinking about multi-finger swipes and such
[23:38] <Jonii_> one touch gesture = one gesture that uses touchpad