| 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) | 01:54 |
|---|---|---|
| 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:49 |
| Satoris | The first one is an issue of Unity and/or GL drivers. | 08:50 |
| Satoris | Four finger taps don't work in Unity 2D, but did they ever? | 08:53 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:28 |
| Satoris | This may be related to why three finger spread does not work. | 11:29 |
| === MacSlow|lunch is now known as MacSlow | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| bregma | GEISv1 chooses one at random, it still mkes no sense but stop people from complaining | 14:20 |
| bregma | if you need to find out of a gesture belongs to a specific class, you need to call geis_frame_is_class() | 14:21 |
| Satoris | There are still a couple of "failed to get previous touch value"s. | 14:22 |
| 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:23 |
| 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:24 |
| Satoris | cnd: preferably Skype today, is that ok? | 14:29 |
| cnd | Satoris, sure | 14:29 |
| Satoris | Excellent, see you then. | 14:29 |
| 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:33 |
| 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 | 14:34 |
| cnd | tvoss, good presentation :) | 15:01 |
| tvoss | cnd, thanks :) my fingers are bleeding :) | 15:01 |
| cnd | heh | 15:01 |
| tvoss | cnd, not literally :) | 15:02 |
| cnd | biab | 15:02 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:34 |
| cnd | ok | 15:35 |
| 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:38 |
| dandrader | cnd, yes | 15:39 |
| 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:40 |
| tvoss | cnd, checking for the logfile | 15:41 |
| cnd | it could just be a difference in which packages are installed? | 15:41 |
| tvoss | cnd, hmmm, no, both vm's are configured equal | 15:42 |
| tvoss | cnd, script altered, build triggered | 15:46 |
| cnd | great | 15:46 |
| === dandrader is now known as dandrader|lunch | ||
| cnd | bregma, I just reviewed your frame daily builder fix | 16:37 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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 | 17:37 |
| * cnd finished his self-evaluation \o/ | 18:59 | |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | It's a big change but on the other hand it's a rather simple one. | 19:05 |
| 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:07 |
| dandrader | no new features | 19:08 |
| cnd | yeah | 19:08 |
| 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:09 |
| cnd | and we have many tests that ensure things are still working properly and no memory is being leaked | 19:10 |
| * cnd -> lunch, biab | 19:12 | |
| cnd | dandrader, I just realized we have a meeting in 17 minutes | 19:13 |
| cnd | would you like to have it now? | 19:13 |
| dandrader | ah, that's true | 19:23 |
| dandrader | sure | 19:23 |
| dandrader | mumble? | 19:23 |
| dandrader | cnd, ^ | 19:24 |
| cnd | dandrader, sounds good | 19:24 |
| cnd | dandrader, any luck with synaptics? | 20:34 |
| dandrader | it's up and running now | 20:34 |
| cnd | is unity working any better? | 20:35 |
| dandrader | gimme a few minutes | 20:35 |
| cnd | k | 20:35 |
| dandrader | forgot that I have to get it from that ppa | 20:39 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:48 |
| cnd | I'm guessing it can query it | 20:49 |
| cnd | bregma? | 20:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 20:57 |
| 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:02 |
| cnd | we picked the wrong units the first time and we learned, and now we need to standardize going forward | 21:03 |
| 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:14 |
| 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:15 |
| dandrader | :) | 21:16 |
| cnd | heh | 21:16 |
| cnd | bregma, luckily, Maverick is out of support on april 10th | 21:17 |
| 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:18 |
| dandrader | what I get is the dash showing up == a 4-touches tap gesture came up | 21:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| cnd | the timeout is calculated from when the gesture starts | 21:31 |
| cnd | which is when the fourth touch goes down | 21:31 |
| dandrader | for a tap gesture, timeout should be from the start time of its oldest touch | 21:34 |
| cnd | dandrader should stop leaving :) | 21:35 |
| cnd | dandrader, you should stop leaving in the middle of a conversation :) | 21:37 |
| 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:38 |
| 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:39 |
| dandrader | my x-chat lost its window decoration. had to restart it | 21:40 |
| 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:41 |
| dandrader | to a 4-touches tap would be when you quickly lay down and lift *4* fingers | 21:42 |
| dandrader | not just one | 21:42 |
| dandrader | s/to a 4/so a 4 | 21:43 |
| cnd | yes, but that's not the only possible definition | 21:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| cnd | if the work to make it function 100% correctly would be large | 21:58 |
| 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:05 |
| cnd | bregma, do you have a strong objection? | 22:06 |
| cnd | I'm still open to change my thoughts if you feel strongly | 22:06 |
| bregma | the more I think about it, the more strongly I feel that now would be the best time to merge it | 22:29 |
| cnd | interesting :) | 22:30 |
| 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:32 |
| 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:33 |
| cnd | agred | 22:34 |
| cnd | agreed* | 22:34 |
| cnd | I think the pros outweigh the cons | 22:34 |
| dandrader | me too | 22:37 |
| 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:41 |
| cnd | dandrader, what gesture were you performing? | 22:43 |
| 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:44 |
| cnd | ahh, ok | 22:45 |
| cnd | I don't know what the difference would be | 22:45 |
| 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:47 |
| 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:49 |
| cnd | dandrader, I have a hard time believing you should still be working today, though :) | 22:50 |
| bregma | addict | 22:50 |
| 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:51 | |
| 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:52 |
| bregma | besides, you need to put in the after-hours work on all your hobby projects | 22:54 |
| cnd | heh | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!