[01:54] <bregma_> cnd: yes, that would be the simple and I believe correct solution (aclocal --install --force will overwrite with a fresh copy if it's available)
[08:49] <Satoris> With dandrader's Unity and newest Grail everything works except three finger spread.
[08:49] <Satoris> It's a bit laggy and the movement is overly sensitive.
[08:50] <Satoris> The first one is an issue of Unity and/or GL drivers.
[08:53] <Satoris> Four finger taps don't work in Unity 2D, but did they ever?
[11:28] <Satoris> Whoah, on my laptop three finger drag is crazy accelerated.
[11:28] <Satoris> Ahah, because it sums up the movements of all fingers.
[11:29] <Satoris> This may be related to why three finger spread does not work.
[14:15] <cnd> Satoris, bregma, dandrader: standups! (tvoss is unavailable)
[14:15] <dandrader> continuing the review of https://code.launchpad.net/~chasedouglas/utouch-grail/touch-states/+merge/99410
[14:15] <Satoris> Testing new Grail & stuff under various circumstances.
[14:15] <bregma> one bug left: working on #944822 (post-hoc device additions to subscriptions)
[14:15] <Satoris> Results in the backlog.
[14:15] <cnd> I'm going to be trying to find a bug in the current grail code :), and doing my own performance review
[14:16] <bregma> cnd has O(n^2) performance
[14:16] <cnd> Satoris, thanks for the testing
[14:16] <Satoris> Np. The spread thing is the biggest issue ATM.
[14:17] <cnd> Satoris, yeah, spread needs fixing
[14:17] <cnd> I can't get it to fire either
[14:17] <cnd> but it's obviously a good sign that grail doesn't have any bugs it seems
[14:18] <cnd> if we can't find a bug we'll have to make a decision on whether to include the touch states changes in precise
[14:18] <Satoris> Why are the gesture names missing in https://bugs.launchpad.net/utouch-geis/+bug/853958
[14:19] <cnd> Satoris, I've not looked at the code myself yet...
[14:19] <bregma> an attribute of "gesture name" makes no sense in GEISv2
[14:20] <bregma> GEISv1 chooses one at random, it still mkes no sense but stop people from complaining
[14:21] <bregma> if you need to find out of a gesture belongs to a specific class, you need to call geis_frame_is_class()
[14:22] <Satoris> There are still a couple of "failed to get previous touch value"s.
[14:23] <cnd> Satoris, yeah, I'm going to look at that today as well
[14:23] <cnd> it's a bug wholly in utouch-frame (or X)
[14:23] <cnd> utouch-frame-test-x11 shows the issue too
[14:23] <cnd> but only for my magic trackpad
[14:23] <cnd> it doesn't on behemoth's touchscreen
[14:24] <Satoris> Failed to get previous value makes perfect sense for a tap, though. It is instantaneous, after all.
[14:24] <Satoris> Though in practice it probably isn't.
[14:29] <Satoris> cnd: preferably Skype today, is that ok?
[14:29] <cnd> Satoris, sure
[14:29] <Satoris> Excellent, see you then.
[14:33] <bregma> cnd, are you going to implement that daily build fix for frame and grail or shall I (I probably have more bandwidth for it)
[14:34] <cnd> bregma, I planned on it, but if you have some spare moments feel free
[14:34] <cnd> I probably won't get to it for another couple hours
[14:34] <bregma> K
[15:01] <cnd> tvoss, good presentation :)
[15:01] <tvoss> cnd, thanks :) my fingers are bleeding :)
[15:01] <cnd> heh
[15:02] <tvoss> cnd, not literally :)
[15:02] <cnd> biab
[15:34] <cnd> tvoss, any ideas why jenkins tests are failing when the device is a trackpad?
[15:34] <cnd> tvoss, would it be possible to save the /tmp/Xorg.gtest.log file as part of the jenkins build output?
[15:34] <cnd> then we'd have a better idea why some tests may fail
[15:34] <tvoss> cnd, otp
[15:35] <cnd> ok
[15:38] <cnd> dandrader, is AtomicRecognizer::ProcessTouches instead of CollectNewTouches good for you?
[15:38] <tvoss> cnd, shouldn't be much of a problem, let me check
[15:39] <dandrader> cnd, yes
[15:40] <tvoss> cnd, quite interesting that all tests pass for amd64
[15:40] <cnd> tvoss, oh...
[15:40] <cnd> I've been running i386 tests
[15:40] <cnd> it would be really handy to get the log file
[15:40] <tvoss> yeah, grail is green for amd64
[15:41] <tvoss> cnd, checking for the logfile
[15:41] <cnd> it could just be a difference in which packages are installed?
[15:42] <tvoss> cnd, hmmm, no, both vm's are configured equal
[15:46] <tvoss> cnd, script altered, build triggered
[15:46] <cnd> great
[16:37] <cnd> bregma, I just reviewed your frame daily builder fix
[17:33] <cnd> bregma, tvoss, dandrader|lunch, so the touch accounting does not seem to fix any functional bugs
[17:33] <cnd> I think it may fix some unbounded memory growth, but we don't have good tests for checking that yet
[17:34] <cnd> it's a pretty big change, so I'd like some feedback on whether we should push it into precise at this stage
[17:34] <cnd> pros: more maintainable touch state accounting
[17:34] <cnd> may fix memory growth issues
[17:35] <bregma> it's definitely a big change, if it does not fix anything I would be hesitant for precise
[17:35] <cnd> cons: big change late in the cycle affecting larg area of code
[17:35] <cnd> we can always branch utouch-grail at this point and apply it to trunk
[17:36] <cnd> I also tend to think that we may be able to resolve unbounded memory growth with a few ERASE_TOUCH fixes in the current code
[17:36] <cnd> so if it is an issue the resolution may not be too difficult
[17:37] <bregma> it should definitely go in eventually, but let's hear what the other guys say about precise... no rush until beta freeze is off, right?
[17:37] <cnd> bregma, correct
[18:59]  * cnd finished his self-evaluation \o/
[19:05] <dandrader> It's a big change but on the other hand it's a rather simple one.
[19:07] <cnd> dandrader, you have an interesting definition of simple :)
[19:07] <cnd> I gather you mean conceptually it's simple
[19:07] <dandrader> simple meaning that it's mostly a refactoring mapping one-to-one the existing functionality
[19:08] <dandrader> no new features
[19:08] <cnd> yeah
[19:09] <cnd> I'm torn because it's not really a necessary bug fix, but I believe it makes the code easier to read, understand, and maintain
[19:09] <cnd> I don't really want to get a week or a month into the 12.04 release and realize that we really do need it
[19:10] <cnd> and we have many tests that ensure things are still working properly and no memory is being leaked
[19:12]  * cnd -> lunch, biab
[19:13] <cnd> dandrader, I just realized we have a meeting in 17 minutes
[19:13] <cnd> would you like to have it now?
[19:23] <dandrader> ah, that's true
[19:23] <dandrader> sure
[19:23] <dandrader> mumble?
[19:24] <dandrader> cnd, ^
[19:24] <cnd> dandrader, sounds good
[20:34] <cnd> dandrader, any luck with synaptics?
[20:34] <dandrader> it's up and running now
[20:35] <cnd> is unity working any better?
[20:35] <dandrader> gimme a few minutes
[20:35] <cnd> k
[20:39] <dandrader> forgot that  I have to get it from that ppa
[20:44] <cnd> dandrader, I know why the pinch to maximize/unmaximize is broken
[20:44] <cnd> there's a behavior change
[20:44] <cnd> I'll make a patch and test it out
[20:45] <dandrader> great. patch for utouch-grail?
[20:45] <cnd> bregma, if you have an opinion on commits for white space fixes, please reply soon
[20:45] <cnd> dandrader, no, unity
[20:45] <cnd> the behavior change is intended
[20:45] <cnd> the pinch radius used to be given in device units
[20:46] <cnd> but that's really not very useful
[20:46] <cnd> the device units vary greatly among devices, and resolutions reported by devices may be non-existent or incorrect
[20:46] <cnd> so now we report the pinch radius as a ratio of the current radius to the gesture start radius
[20:48] <dandrader> cnd, would be great to have it documented in geis.h :)
[20:48] <cnd> this behavior change is pretty big, but I think it's necessary
[20:48] <cnd> well, it's not a function of geis
[20:48] <cnd> it's a function of the backend
[20:48] <cnd> we could document it in the geis header, what is expected depending on the backend
[20:48] <dandrader> but does the geis client has any knowledge on the backend used?
[20:49] <cnd> I'm guessing it can query it
[20:49] <cnd> bregma?
[20:50] <dandrader> it's kinda odd the a geis client has to if{}else{} his code according to the backend used...
[20:50] <dandrader> s/the a/that a
[20:51] <cnd> yeah
[20:51] <cnd> it's not the best solution
[20:51] <cnd> we could make the geis layer report the attrs in device units again
[20:51] <cnd> but it would be a step backwards...
[20:52] <dandrader> couldn't it always be "as a ratio of the current radius to the gesture start radius"?
[20:52] <cnd> dandrader, what do you mean?
[20:53] <bregma> cnd, I already commented on the whitespace issue
[20:53] <dandrader> I mean having the geis layer always reporting the attributes in those more useful units
[20:53] <cnd> bregma, ok, just checking if there's anything more you wanted to add
[20:54] <cnd> dandrader, that's essentially what it does now
[20:54] <cnd> it only reports the ratio
[20:54] <cnd> in the past it reported device coordinate units
[20:55] <dandrader> and why can't we make that behavior backend-independent?
[20:55] <dandrader> so that we can document it and users rely on it
[20:55]  * dandrader is confused
[20:55] <bregma> we currently only have one real back end
[20:55] <cnd> dandrader, well, making it backend independent would mean making the old, obsolete, no longer available xcb backend use the ratio too
[20:55] <cnd> there's really no use for updating the xcb backend
[20:56] <bregma> (the dbus back end should be invisble)
[20:56] <bregma> if it's documented, though, any future back end will need to reproduce the behaviour somehow
[20:56] <bregma> (think: Windows, iOS)
[20:56] <cnd> dandrader, the xcb backend was only ever available in ubuntu, as far as distros go
[20:57] <cnd> so it's really really dead now
[20:57] <cnd> bregma, good point
[20:57] <dandrader> bregma, and isn't that a good thing? or could that be impossible?
[20:57] <cnd> I'm thinking one big task that must be completed first in the Q cycle is full API documentation, behavior documentation, and architecture documentation
[21:02] <cnd> dandrader, I think bregma is just saying that going forward we need to document it and stick to it
[21:02] <cnd> now that we really may attempt to work cross-platform, cross-distro, etc.
[21:03] <cnd> we picked the wrong units the first time and we learned, and now we need to standardize going forward
[21:14] <cnd> dandrader, if I give you a small patch to make pinch work, would you mind applying it to your tree again?
[21:14] <cnd> http://paste.ubuntu.com/902870/
[21:15] <dandrader> np
[21:15] <bregma> sorry, my wife just came home and told me about her day (priorities)... yes, I mean we need to document it and stick to it, we needed better documentation for M, let alone Q
[21:16] <dandrader> :)
[21:16] <cnd> heh
[21:17] <cnd> bregma, luckily, Maverick is out of support on april 10th
[21:18] <bregma> I guess I can close that outstanding geis bug then
[21:18] <dandrader> cnd, try that: 1- slide 3 fingers on the touchpad like crazy to that you start dragging a window 2- about ~ 1 sec later let a 4th finger on the trackpad
[21:18] <dandrader> s/to that/so that
[21:19] <dandrader> what I get is the dash showing up == a 4-touches tap gesture came up
[21:20] <cnd> dandrader, so I'm moving a window with 3 touches
[21:20] <cnd> and then I put a 4th down?
[21:20] <cnd> and continue moving?
[21:21] <dandrader> no. put a 4th down a lift it
[21:21] <dandrader> while the other 3 remain down
[21:21] <cnd> dandrader, so essentially do a tap with a 4th finger?
[21:22] <dandrader> cnd, yes! :)
[21:22] <cnd> ok, so it shows the dash when I do that
[21:22] <cnd> :)
[21:22] <dandrader> so we got ourselves a new bug!
[21:22] <cnd> which is expected behavior with how we have architected the stack
[21:23] <cnd> the question is: did we architect it wrong
[21:23] <cnd> or do we need to fix unity
[21:23] <cnd> or even: is it really a bug?
[21:24] <cnd> this is actually behavior that tracks way back while we were developing the very first version for maverick
[21:24] <cnd> it was behavior requested by sabdfl himself :)
[21:25] <cnd> not saying that means we shouldn't change it
[21:25] <cnd> implicitly leaving the subject of a sentence off doesn't work as well over irc...
[21:26] <cnd> I'm not saying that means we shouldn't change it
[21:26] <dandrader> I put 3 fingers down, move them around like crazy, then I tap with a fourth finger, while the first 3 stay put <= that can't be a 4-touches tap!
[21:26] <cnd> I designed the new utouch architecture to mimic the old architecture unless I thought it was obviously wrong, like the pinch units
[21:27] <cnd> I can't say that I can think of a reason we should make this act like a 4 touch tap
[21:27] <cnd> and when we switch to geis v2 and the regular recognizer it will be more obvious what is going on
[21:28] <cnd> though that will require matching up touch ids
[21:28] <cnd> which we could do here just as easily
[21:28] <cnd> dandrader, to sum up my thoughts: we should keep track of the touches of a gesture
[21:28] <cnd> if a tap includes touches of a previous gesture, we should not honor it
[21:29] <dandrader> one problem in my example is that 3 out of the 4 fingers that comprise that 4-touches tap have moved way beyond the movement threshold for a tap
[21:30] <cnd> dandrader, yes, but then you left them stationary during the "tap"
[21:30] <dandrader> and they also have been down for way too much time to configure a tap
[21:31] <cnd> the timeout is calculated from when the gesture starts
[21:31] <cnd> which is when the fourth touch goes down
[21:34] <dandrader> for a tap gesture, timeout should be from the start time of its oldest touch
[21:35] <cnd> dandrader should stop leaving :)
[21:37] <cnd> dandrader, you should stop leaving in the middle of a conversation :)
[21:38] <cnd> dandrader, the problem with your approach is that it doesn't allow the flexibility of someone who *does* feel that it should be a four touch tap to receive the gesture
[21:39] <cnd> I don't like the idea of taking away a potential use case for everyone when the alternative is to tell some people to just filter out gestures they don't want
[21:40] <dandrader> my x-chat lost its window decoration. had to restart it
[21:41] <cnd> that sounds like it hurts :)
[21:41] <dandrader> restarting compiz has its problems :)
[21:41] <cnd> heh
[21:41] <bregma> compiz bug, I believe
[21:41] <dandrader> the thing is: what's the definition of a tap/
[21:41] <dandrader> for me it's when you quickly lay down an lift a finger
[21:42] <dandrader> to a 4-touches tap would be when you quickly lay down and lift *4* fingers
[21:42] <dandrader> not just one
[21:43] <dandrader> s/to a 4/so a 4
[21:43] <cnd> yes, but that's not the only possible definition
[21:44] <cnd> a tap could be defined as when going to a specific number of touches and then leaving that number of touches within a specified interval
[21:44] <cnd> the initial and end states are undefined and can be anything
[21:46] <dandrader> In the use case I described earlier. I think if there would be a tap gesture there it would be a 1-touch tap (containing only the 4th finger).
[21:47] <dandrader> that would come and go while the 3-touches drag is still going on
[21:47] <dandrader> that in a non-atomic recognizer
[21:47] <cnd> then you've got multiple simultaneous gestures on a trackpad
[21:48] <cnd> though that would be one appropriate response for a touchscreen
[21:48] <cnd> dandrader, I guess my thinking is that this is a policy question
[21:48] <cnd> "what is the definition of a multi-touch tap"
[21:48] <cnd> and we can try to define the policy in the utouch stack
[21:48] <cnd> or we can give all the info to the client and ask them to enforce whatever policy they want
[21:51] <dandrader> I didn't really get what you meant by policy there, but that sounded like you want the client to do at least part of the work of gesture recognition...
[21:51] <cnd> yes and no
[21:51] <cnd> for me, a robust gesture system provides the client with gestures
[21:52] <dandrader> or should we have two kinds of tap gestures?
[21:52] <cnd> and the client decides which ones apply for the given context
[21:53] <dandrader> according to my definition of a tap. what should a client have to do to get it?
[21:53] <cnd> if they just listen to N-touch taps, then they don't have to do anything
[21:54] <cnd> if they are more complex, and listen to M-touch gestures and N-touch taps, where N > M
[21:54] <cnd> then they should check if the N-touch tap gesture is comprised only of touches who begin as part of the gesture
[21:55] <cnd> unfortunately, geis v1 doesn't expose all the grail slices of a gesture, so that approach won't work here
[21:55] <cnd> but we can find a work around as a stop-gap measure
[21:56] <bregma> GEISv1 exposed all the touches of each gesture
[21:56] <cnd> bregma, yes, but not all the "slices"
[21:56] <cnd> to give an example
[21:56] <cnd> you have a two touch tap
[21:56] <dandrader> hmm... If the geisv2 version of Unity doens't have this issue then here's our ticket to get the geisv2 refactoring on board :D
[21:56] <cnd> in geis v1 and geis v2 without tentative events, you will receive only one geis event
[21:57] <cnd> dandrader, heh, we can more easily work around the issue in geis v1 than by moving to geis v2
[21:57] <cnd> dandrader, I'm inclined in general to write this one specific bug off as won't fix, anyways :)
[21:57] <cnd> i.e. unsupported
[21:58] <cnd> if the work to make it function 100% correctly would be large
[22:05] <cnd> bregma, dandrader: if you're still around, I'm leaning toward merging the touch accounting branch
[22:05] <cnd> I think dandrader is in agreement
[22:06] <cnd> bregma, do you have a strong objection?
[22:06] <cnd> I'm still open to change my thoughts if you feel strongly
[22:29] <bregma> the more I think about it, the more strongly I feel that now would be the best time to merge it
[22:30] <cnd> interesting :)
[22:32] <bregma> I think it's a slightly better architecture and if we have to maintain the code over the lifetime of the LTS release, it should go in now
[22:33] <bregma> my only reservation is that it is not a trivial change and does not fix any bugs, so technically it does not quality for going in to precise at this point in the release cycle
[22:34] <cnd> agred
[22:34] <cnd> agreed*
[22:34] <cnd> I think the pros outweigh the cons
[22:37] <dandrader> me too
[22:41] <dandrader> there's a very well defined period of silence in grail right after I start a 3 or 4 touches gesture. but that doesn't happen with 2 touches. any ideas? (I would like to blame synaptics, as usual)
[22:41] <cnd> dandrader, you normally won't receive two touch gestures...
[22:41] <bregma> I have no problem bending the release rules a little if you're confident the change does no harm and dandrader is favourably inclined
[22:41] <dandrader> cnd, that's what output looks like http://paste.ubuntu.com/902989/
[22:43] <cnd> dandrader, what gesture were you performing?
[22:44] <dandrader> cnd, any 3 or 4 fingers movement
[22:44] <cnd> dandrader, if you cross the drag threshold before the 300 ms timeout, it should immediately start sending events
[22:44] <dandrader> and for the two touch gestures, I just followed your instructions on how to remove interference from x stuff via synclient and xinput set-prop
[22:44] <cnd> if you just lay your fingers there for 300 ms, it will wait
[22:45] <cnd> ahh, ok
[22:45] <cnd> I don't know what the difference would be
[22:47] <dandrader> that silence period is what causes the jumps in my gestures
[22:47] <cnd> hmm
[22:47] <dandrader> like the launcher jumping to its final position on a 4-touches drad
[22:47] <dandrader> drag
[22:47] <cnd> I don't get it here
[22:49] <cnd> dandrader, you're running synaptics now?
[22:49] <dandrader> yes
[22:49] <cnd> cool
[22:49] <cnd> dandrader, so when the gesture crosses the threshold for the subscription, it should flush the slices
[22:49] <cnd> so that's where I would start debugging
[22:49] <cnd> to see why slices aren't being flushed
[22:50] <cnd> dandrader, I have a hard time believing you should still be working today, though :)
[22:50] <bregma> addict
[22:51] <dandrader> I had a looong lunch break today. had to go to the bank, fetch my repaired bike from the shop, etc
[22:51]  * cnd fears we are all pots calling the kettle black :)
[22:52] <cnd> dandrader, I wouldn't worry too much if it's a one-time issue, btw
[22:52] <cnd> if you average 40 hrs a week, with a couple hours of variation, you're fine :)
[22:54] <bregma> besides, you need to put in the after-hours work on all your hobby projects
[22:55] <cnd> heh