/srv/irclogs.ubuntu.com/2012/03/16/#ubuntu-touch.txt

cndk00:05
cndI've got a pipeline of multiple geis and grail fixes00:06
cndhopefully I can send some of them out today00:06
=== MacSlow is now known as MacSlow|lunch
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== MacSlow|lunch is now known as MacSlow
cndtvoss, bregma, Satoris, dandrader: standups!15:14
tvossDeployed the new web service on staging, working on trackpad-recognizer15:14
cndI started unraveling multiple bugs in grail and geis yesterday, I'll be continuing today15:14
cndthey revolve around making taps work properly15:15
tvosscnd, with missing begins?15:15
cndtvoss, unless you opt for tentative events using geis, taps will only appear as one "update" event15:15
cndtvoss, or are you asking about grail events?15:15
tvosscnd, about grail event15:16
tvoss+s15:16
cndtvoss, I'm unaware of missing begins for tap events15:16
tvosscnd, checking ... gimme a second15:16
bregmaI'm fixing up utouch-geis with a cunning gtest autoconf solution15:16
dandraderI'm checking what's missing on unity gestures. Currently fine tuning subscriptions on my geisv2 version of unity gestures code.15:16
cndbregma, will it be using the xorg-gtest autotools foo?15:17
cndI'd rather we had the same autotools foo in every project, and it might as well be derived from xorg-gtest15:17
tvosscnd, https://bugs.launchpad.net/utouch-grail/+bug/94985515:17
dandraderI'm also waiting for cnd to publish his fixes to check how my fix for the 3-touches drag on top of unity trunk (without the geisv2 refactoring) work15:17
cndtvoss, yes, I'm fixing that bug15:17
SatorisRedesigning and -factoring aptng plus finalising touches on Chromium.15:17
dandraderbecause now, on top of geis b1, things are rather wild15:17
bregmathe xorg-gtest stuff is way too complicated and unusual15:18
=== dandrader is now known as dandrader|lunch
cndbregma, then propose changes in xorg-gtest15:18
cndI Cc'd you on the patches for a reason :)15:18
cndnone of them have been committed yet15:18
bregmaI will propose changes in libgtest-dev first, then they should propagate through consumers of that package15:18
cndbregma, you're going to add stuff to libgtest-dev?15:19
cndwe won't be able to use it in xorg-gtest upstream15:19
bregmaI can propose an upstream patch, it won;t hurt15:19
cndbecause the changes in libgtest-dev won't be upstream15:19
cndyeah, that would be good15:19
cndbut until then, we can't rely on the functionality15:19
bregmaif it'rejected upstream, I go to the next step15:19
bregmait's just an m4 file and two variables in your .am file15:20
bregmait works in geis, I'll see if I can rejig it for xorg-gtest15:20
cndk15:21
cndbregma, multiple people in PS are asking about how to fix their gtest autofoo15:43
cndrather than give potentially bad info15:43
cndwhat is wrong with what I've proposed for xorg-gtest?15:43
bregmacnd, principle of least surprise:  no other package requires including automake snippets, neither does my solution15:49
bregmayou just add one macro to configure.ac, add a file to the _SOURCES target, and add the usual _CFLAGS15:50
bregmaand guanateed the gtest is compiled with EXACTLY the same flags used for all the other files in the test15:51
cndbregma, what's the difference between requiring people to edit their Makefile.am and asking them to copy a different automake file and include it?15:51
bregmaprinciple of least surprise:  no other package requires including automake snippets15:51
cndyeah, but that's because autotools doesn't really support building sources from elsewhere15:51
bregmaany other package I just add a line to configure.ac and add _CFLAGS and _LIBS to the appropriate places15:52
bregmaautotools supports building from source just fine15:52
bregmaafter all, that's it's mainpurpose in life15:53
cndyeah, but it doesn't have good support for building from a system provided location15:53
cndbregma, either way, RAOF is looking at creating a real Makefile snippet15:54
cndso you merely include the Makefile, which is installed in the system15:54
bregmayou don;t need a makefile snippet15:54
bregmayou do not need a big fancy solution when a simple solution that works like any other package will do15:55
bregmawe do not need to reinvent the autotool here15:55
cndit doesn't work like any other package because with other packages you would just link against the system installed precompiled library15:56
bregmait works like any other package:  include the macro in configure.ac, add the variables to your targets in your .am files where needed15:56
bregmathat what all the other packages do, that's what my solution does15:57
cndI think the devil is in the details, I'll wait to see what you have15:58
bregmagah, gtest has no way to automatically determine its version, better hope its API never changes15:58
cndheh15:59
cndgtest really needs a pkgconfig and an aclocal macro15:59
cndactually, pkgconfig is probably enough15:59
bregmathat would be best16:03
bregmamaybe that's what I'll propose for upstream16:04
cndyeah16:05
=== dandrader|lunch is now known as dandrader
dandraderwhat do I use a GeisRegion for?16:40
dandraderI create one with geis_region_new() and that's it? Or can I pass it to geis_filter_add_term()?16:42
cndyay, geis gesture accept/reject ffe is approved :)16:48
bregmadandrader, you probably do not ever need to create a geis_region, it's more for non-X11-window-based recognizers16:56
bregmaof which we have none at the moment16:56
bregmacnd, how stable is utouch-frame (as in, do you think we will need another release before RC)?16:57
cndbregma, I can't remember any changes to it, nor any bugs in it16:58
bregmastable is nice17:00
bregmaespecially for packaging for Debian17:01
dandraderbregma, so currently utouch-geis code doesn't use GeisRegion for anything at all, right? (at least that's what grep tells me)17:01
bregmadandrader, yes, reserved for future use17:21
bregmacnd, now that the FFe has been approved, do you think I should just upload utouch-geis 2.2.6 as-is and risk build failure or should I reroll the source tarball to include the PPA fix just in case?17:47
bregmait's stupid if all of precise is built on a jaunty chroot17:47
cndbregma, I actually have a few changes that I will be proposing today17:48
bregmachanges should go in 2.2.717:48
cnddid you already release 2.2.6 upstream?17:48
bregmaa couple days ago, all the targeted bugs were fixed17:48
cndok17:49
bregmaI can not upload 2.2.6 at all and wait for 2.2.717:49
cndhmm17:49
cndI think it's fine either way17:49
cndif you upload it17:49
cndtry it first17:49
cndand then distro patch the epoll fix if it breaks17:50
cndthat's what I would suggest17:50
bregmahmm, yeah, that would work, too17:50
bregmaOK, sounds like a plan17:50
bregmawe can release 2.2.7 and the new grail next week17:50
cndyeah17:50
cndI'm so close to having this tapping bug fixed17:51
cndgeis generates one update event17:51
cndwith the correct number of touches17:51
cndbut the event never gets seen in the testcase...17:51
cndbregma, I think our highest priority task right now is to figure out the xorg-gtest madness17:54
cndif you can get a patch for it it would be great17:54
cndbasically, lop off the second to last patch in my source branch in my git repo17:55
dandraderI put my fingers on a touchscreen and leave them still for some 3 seconds, after that I drag them over the screen. Should a drag gesture happen?18:00
bregmacnd, I'll do that next18:01
cnddandrader, not with the default drag threshold and timeout18:01
dandraderI'm not sure if it's a question of parameter values18:03
bregmaheh, nope, precise is built on builders using a 6-year-old kernel18:08
bregmaI'm surprized there are not more failures then18:09
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
cndbregma, I just filed a pipeline of changes for geis18:55
cndthey require some grail fixes18:55
cndI don't have a pipeline and tests for grail fixes yet, but I do have a work in progress branch that has the fixes: lp:~chasedouglas/utouch-grail/work-in-progress18:55
cndI don't think geis will break if run against the current grail, it just won't be fully fixed18:56
cndso the changes can be merged before the grail fixes are18:57
cndI need to file a bug for the geis issue...18:58
bregmaI'mm off to chauffeur people around for an hour or so, back in a bit19:08
bregmacnd, which is the upstream xorg-gtest these days?22:18
cndyou can use lp:xorg-gtest if you want, it's synced automatically, but the real upstream is http://cgit.freedesktop.org/xorg/test/xorg-gtest/22:19
cndhowever, I have 8 commits in my source branch at http://cgit.freedesktop.org/~cndougla/xorg-gtest/ that you will want to base your work on22:19
cndeverything except the second to last commit22:19
cndI should probably apply the other commits at the point22:20
cndthe only real question is how to handle the one commit that adds the infrastructure for other projects22:20
bregmaOK, that's what I'm really looking for22:20
cndif you give me a minute, I'll push the other commits22:20
bregmano hurry22:22
cndbregma, I've updated upstream master branch22:25
bregmathanks22:25
cndand I just updated my source branch22:25
cndit only has that one commit now22:25
cndbregma, you can use that as a basis if you want22:26
bregmaI'll be playing with stuff for the next little while but it's well past EOB on a Friday night here, so don;t get your hopes up for a patchset tonight22:26
bregmaI'm still wading through the geis merge requests22:26
cndbregma, sure, np22:29
* cnd turns on the purdue st mary's basketball game on his ipad next to his monitor23:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!