[08:17] <Satoris> Touch behaviour has changed. If I put down three fingers and drag, I get window movement. If I put down two, drag, and then put down a third, I don't get window movement, the touches go to the app.
[08:18] <Satoris> Earlier three fingers were always grabbed. Is this intentional?
[08:31] <Satoris> Also, if the window manipulation handles appear, the application still gets the touches. This is also different.
[11:51] <Satoris> Does Unity 2D crash on login for anyone else? I filed a bug on it, but it's currently private so I can't link to it.
[12:26] <Satoris> Apparently touch propagation is different depending on whether you consume XInput events from the virtual pointer or the device directly.
[12:40] <Satoris> Is Bluetooth pairing broken today? [ ] yes [ ] no [ ] only on some machines
[14:14] <cnd> good morning everyone :)
[14:14] <tvoss> refactored chromium patch according to feedback from devs, working on integration tests for the patch (evemu-based), jenkins vm setup (beta2 and arm)
[14:14] <cnd> bregma, Satoris, tvoss: standups!
[14:14] <tvoss> hi chase :)
[14:15] <cnd> there are a couple X server and synaptics bugs that I need to get fixed
[14:15] <Satoris> Trying to flush out bugs since the old ones are fixed. Found stuff in the backlog. Did not file bugs as I did not know if they are intentional.
[14:15] <cnd> I'll try to fix them today, and then help out with any bugs
[14:16] <tvoss> cnd, @evemu testing: can we move utouch::evemu::Recording and utouch::evemu::Device out of grail into evemu?
[14:16] <cnd> Satoris, yes, touches are sent through both the master and the slave device
[14:17] <Satoris> cnd: but they are delivered differently.
[14:17] <cnd> tvoss, do you mean testing::evemu::Recording and Device?
[14:17] <tvoss> cnd, ack
[14:17] <cnd> Satoris, yeah
[14:17] <cnd> tvoss, they are in xorg-gtest now
[14:17] <cnd> just need to convert grail over
[14:17] <tvoss> cnd, cool, will use xorg-gtest in chromium then :)
[14:17] <cnd> heh
[14:18] <tvoss> cnd, for adding a test for the patch
[14:18] <cnd> Satoris, touches from master and slave devices are completely independent
[14:18] <cnd> if you grab on one device, you will still be allowing thouches through the other
[14:19] <cnd> well, if you grab the slave it detaches from the master, so I guess that's different
[14:19] <Satoris> I find it counterintuitive that Unity steals three finger touches from core pointer but not the device itself.
[14:20] <cnd> Satoris, yeah, but it's how xinput is supposed to work
[14:20] <Satoris> Ok. What about the continuation thingy?
[14:21] <bregma> I'm trying to run everything through valgrind today to make sure stuff is clean in that respect
[14:22] <cnd> Satoris, if it's a behavior break, then the old behavior was wrong I think
[14:22] <cnd> this area isn't really spec'd out too well, IIRC
[14:23] <cnd> hmm, actually, thinking some more
[14:23] <cnd> we may have to do it that way
[14:24] <cnd> I'm imagining a scenario where the application has 0 threshold drags for scrolling
[14:24] <Satoris> It seems cleaner to me that you have to start with three fingers to get the window manipulation actions. But this is a change in behaviour and I worry about getting nasty emails on this :)
[14:24] <cnd> the two touch gesture will fire immediately
[14:24] <cnd> but when you put a third touch down, it must cause a unity gestures
[14:25] <cnd> wait, that's why we have the glue, or construction, time...
[14:25] <cnd> ok, I think we have it right
[14:25] <Satoris> I dislike Unity stealing my two finger drags if I accidentally touch the touchpad with a third finger.
[14:25] <cnd> yeah
[14:26] <Satoris> The correct behaviour is somewhere in the design team's brains. I have no idea what it is.
[14:27]  * cnd wonders where dandrader is
[14:27] <bregma> at the bank
[14:27] <bregma> looking for a banker that won;t rip him off
[14:27] <bregma> best of luck
[14:28] <Satoris> I hope he remembered to take his shotgun along.
[14:29] <cnd> oh right
[14:31] <tvoss> cnd, do we have a conf call today?
[14:31] <cnd> we're supposed to
[14:31] <cnd> I'm dialed in
[14:31] <tvoss> cnd, same here, pinged olli
[14:33] <cnd> Satoris, when leaving bug feedback that requires the user to provide feedback, remember to move the bug to incomplete
[14:33] <cnd> it starts the expiration timer on the bug :)
[14:33] <bregma> off the hook this week
[14:33] <cnd> bregma, off the hook?
[14:33] <olli> aufgeschoben ist nicht aufgehoben ;)
[14:34] <Satoris> Ok.
[14:34] <olli> ask tvoss to translate
[14:34] <cnd> bregma, Satoris: no meeting
[14:34] <cnd> it'll be rescheduled
[14:34] <cnd> and olli is giving us $100 each in compensation
[14:35] <tvoss> aufgeschoben ist nicht aufgehoben = postponed but not cancelled
[14:35] <tvoss> cnd, ;)
[14:35] <cnd> tvoss, the compensation bit was in that german sentence, wasn't it?
[14:36] <tvoss> cnd, no, the german sentence basically means: I'm coming back to you guys, don't think you are done yet ;)
[14:36] <tvoss> cnd, thinking more about it: yes, it was part of the sentence
[14:36] <cnd> right
[14:36] <cnd> :)
[14:37] <Satoris> Especially if you interpret it as Switzerland German rather than hochdeutsch.
[14:37] <bregma> if you were Austrian, I image you'd say something like "hasta la vista, baby... I'll be back"
[14:38] <cnd> heh
[14:39] <cnd> Satoris, any updates on the bug counter script?
[14:39] <Satoris> It's better than "Come with me if you want to live!".
[14:39] <Satoris> cnd: dynamic detection won't work until launchpadlib is fixed. Other than that it works just fine.
[14:40] <cnd> hmm... it worked fine for me using the launchpadlib example script
[14:40] <cnd> why is it different for us?
[14:40] <Satoris> Because it uses a different Python library. The imports are different.
[14:41] <Satoris> https://bugs.launchpad.net/launchpadlib/+bug/968952
[14:41] <cnd> Satoris, we should be using arsenal
[14:42] <cnd> I would like to get this merged into arsenal, and creating qa reports like other teams are doing
[14:42] <cnd> I think that's the proper end goal for this project
[14:42] <Satoris> Should I file a merge request now or after the bug has been fixed?
[14:43] <cnd> Satoris, well, we need to fix the script so it uses arsenal and can get the team-subscribed packages
[14:43] <cnd> arsenal also has web page templates that we need to integrate with or extend
[14:44] <Satoris> What sort of integration do you mean? The arsenal scripts that I have looked at (granted, only a few) are straightforward "get stuff from Launchpad using the API and print it".
[14:44] <Satoris> Output formats, sure.
[14:45] <cnd> whatever integration is needed to get the subscribed packages/projects
[14:45] <cnd> since it works through arsenal somehow
[14:45] <cnd> but then also whatever integration is needed for the web page qa reports too
[14:46] <Satoris> Which is the Correct and Supported Python library to use? Launchpadlib or the other one that Arsenal scripts use?
[14:48] <Satoris> All documentation that I see points to Launchpadlib.'
[14:49] <cnd> for the ubuntu qa stuff, I would say arsenal
[14:49] <cnd> it's maintained by many teams across ubuntu
[14:49] <cnd> with launchpadlib, we'd be on our own
[14:50] <cnd> and the purpose of arsenal is to make launchpadlib easier to work with, though I can't personally attest to how true that is
[14:50] <Satoris> So essentially what we are talking about is a complete rewrite?
[14:51] <Satoris> And looking (again, cursorily) at Arsenal, it seems more like a collection of scripts than an actual library.
[14:51] <cnd> of a 146 line script?
[14:52] <Satoris> Well, yes.
[14:52] <cnd> Satoris, let's plan for the end goal
[14:52] <cnd> we want a bug report that is updated routinely and available for people to see
[14:52] <cnd> the arsenal platform does this for many other teams
[14:53] <cnd> and has extensible (hopefully) html qa report templates
[14:53] <cnd> so although we can make a cli script that everyone has to run individually, integrating into the existing projects used by other teams is a better long-term solution
[14:54] <cnd> and would allow devs to bookmark a url
[14:54] <Satoris> Yes.
[14:56] <cnd> tvoss, I can't access the jenkins web portal for creating one-shot jobs
[14:56] <Satoris> What I'm concerned about is the data acquisition backend.
[14:57] <cnd> Satoris, what concerns do you have?
[14:57] <Satoris> Why do they use a different Python API? Why are there two? Is one of the deprecated?
[14:58] <Satoris> If yes, which one?
[14:59] <cnd> python-launchpadlib-toolkit is built on top of launchpadlib
[14:59] <cnd> neither is deprecated
[14:59] <cnd> the toolkit is hopefully easier to use
[14:59] <cnd> but documentation is scarce for both
[14:59] <tvoss> cnd, checking, thanks for the hint
[15:00] <Satoris> Ok, I'll change it to use Arsenal tomorrow.
[15:01] <cnd> Satoris, sounds good, and then look into the html report templates
[15:01] <cnd> see if you can get it all hooked up so we have nice looking reports
[15:01] <cnd> in the end, I think we will want to modify an existing template
[15:01] <cnd> so we can see all the bug tasks for a given bug
[15:02] <tvoss> cnd, up and running again, checking why it was terminated
[15:02] <cnd> currently, I think all the other reports are for ubuntu downstream only
[15:03] <Satoris> Till tomorrow then.
[15:08] <tvoss> cnd, is the 99-virtual-device-conf snippet already in xorg-gtest?
[15:08] <cnd> tvoss, it's in git
[15:08] <cnd> but it hasn't been released yet
[15:08] <tvoss> cnd, ack, preparing the beta2 vm's currently
[15:47] <tvoss> cnd, frame, grail and geis all need --enable-integration-tests?
[15:52] <bregma> they should, yes
[15:53] <tvoss> thanks
[15:58] <cnd> tvoss, it's automatic
[15:58] <cnd> they don't need it if all the dependencies are available
[15:58] <cnd> like xorg-gtest
[15:58] <cnd> and evemu
[18:19] <dandrader> cnd, it's gonna be painful to put those fixes into 12.04 Unity
[18:19] <cnd> hmm?
[18:19] <dandrader> they wanna see tests (I can't blame them for that)
[18:19] <dandrader> the gesture fixes
[18:19] <cnd> hmm... ok
[18:19] <cnd> dandrader, well, we need to do the best we can
[18:19] <cnd> dandrader, feel free to ask for help
[18:20] <cnd> dandrader, can you subscribe utouch-team to the merge proposals?
[18:20] <dandrader> sure. the interesting thing is that unity gestures code have never received any kind of testing at all, so it seems
[18:21] <cnd> dandrader, yeah
[18:21] <cnd> I would love to say that it's not our fault it doesn't have any tests
[18:21] <cnd> but I think it'll fall on deaf ears
[19:31] <tvoss> cnd, dandrader you could propose manual tests in the mp :)
[19:32] <dandrader> tvoss,  yeah, the last resort
[19:32] <cnd> yeah, I think that's the most straightforward
[19:33] <cnd> but I don't know what the difference is between an autopilot test and a unit test
[19:33] <cnd> I think asking the unity team for help in determining the best course of action may help
[19:33] <tvoss> cnd, an autopilot test basically means specifying behavior and expected result in terms of unity state
[19:33] <cnd> they can give guidance on how tests could be factored
[19:34] <cnd> tvoss, would that work here?
[19:34] <tvoss> cnd, dandrader you might want to ask thomi or lamalex, they are the autopilot gurus
[19:34] <tvoss> cnd, I do not know as autopilot might only be able to move the mouse pointer, but lacking infrastructure to inject touches
[19:34] <tvoss> ah, wait ... evemu has a python wrapper, right?
[19:34] <cnd> tvoss, yes
[19:35] <cnd> but you'd need a full stack
[19:35] <cnd> kernel, X server, etc.
[19:35] <cnd> is that all available in the autopilot tests?
[19:35] <tvoss> cnd, yes, they are providing a full featured setup
[19:35] <cnd> ok
[19:35] <cnd> then that may work
[19:36] <tvoss> cnd, then it might be well possible to think about an autopilot test, like: replay recording and check whether unity recognized a 3-finger drag and triggered the respective action
[19:36] <cnd> yeah
[19:40] <lamalex> tvoss, it shouldn't be very hard to add support though
[19:41] <lamalex> it'd actually be very good for us to add multi touch emulation support into autopilot
[19:41] <lamalex> so those features are getting testing
[19:41] <tvoss> lamalex, great ... can you help with that? I'm pretty much a noob regarding autopilot and it would take me some time to dive into it
[19:42] <lamalex> tvoss, it's really, really, really simple
[19:42] <tvoss> lamalex, okay, any hints? :)
[19:43] <lamalex> start with lp:unity tests/autopilot/autopilot/emulators
[19:43] <lamalex> take a look at X11.py for how we do the mouse and such
[19:43] <lamalex> you're basically just writing a wrapper for utouch that is a fake user using utouch
[19:43] <tvoss> lamalex, okay, will take a look ... let's see if I can make any meaning out of it
[19:44] <lamalex> tvoss, most of the complex code in autopilot is related to unity- not really the mouse/keyboard bits. those are really simple
[19:44] <lamalex> if you've got any questions though just give  a ping
[19:44] <tvoss> lamalex, great, thanks :)
[19:50] <cnd> lamalex, have you guys looked into xorg-gtest by any chance?
[19:51] <cnd> I don't really know how you have the testing set up
[19:51] <cnd> but if it's gtest-based, then it may help
[19:54] <lamalex> no, it's all python- it's based on the testtools/unittest
[19:55] <cnd> ok
[20:03] <tvoss> lamalex, do I understand that correctly that we only would need a class MultiTouchDevice in X11.px that offers methods like PlayFourTouchDrag for example?
[20:04] <lamalex> yup
[20:04] <lamalex> thats about right
[20:04] <lamalex> might want something like FourFingerDrag(x1, y1, x2, y2, path)
[20:31] <dandrader> lamalex,  should "make check" from unity/build also run those autopilot tests or do I need to do something else to make it work?
[21:02] <dandrader> ok, so I need to run unity/tools/autopilot and there's no longer a run_autopilot...
[23:25] <cnd> oh bregma...
[23:25] <cnd> I forgot to tell you
[23:26] <cnd> I had to branch lp:utouch-frame/ubuntu to lp:utouch-frame/precise
[23:26] <cnd> because the debhelper 9 stuff would be a feature freeze break
[23:34] <cnd> bregma, according to slangasek, we need to test build everything that has a build-depends on utouch-frame now
[23:34] <bregma> what do you mean?
[23:34] <cnd> utouch-grail, mtview, geis
[23:35] <cnd> bregma, so you uploaded a version of utouch-frame that has multiarch
[23:35] <cnd> before friday, utouch-frame did not have multiarch
[23:35] <bregma> right, but is that not the default in precise?
[23:36] <cnd> switching from non-multiarch to multiarch is a change that requires a FFe
[23:36] <cnd> because it can break builds
[23:36] <cnd> rather than revert what's already done, we need to test build all the packages that build-depend on frame
[23:36] <cnd> pdebuilds
[23:37] <bregma> everything in the utouch stack should be on debhelper 9, and multi-arch, now
[23:37] <bregma> I did not know it required a FFe
[23:37] <cnd> I should have mentioned it when I branched the packaging branches
[23:38] <bregma> what was the information path through which you found out it required a FFe?
[23:38] <cnd> I asked on #ubuntu-devel
[23:39] <cnd> just cause I had a feeling it might be something that required it
[23:40] <bregma> the only way there could be a breakage is if something hard codes the path to the libraries instead of using the pkg-config files
[23:41] <cnd> yeah
[23:41] <cnd> I'm going to run pdebuild on the packages
[23:43] <bregma> you know I already did that before I uploladed utouch-geis
[23:44] <cnd> bregma, did what?
[23:44] <bregma> I've rebuild evemu,frame,grail,and geis in my pbuilder
[23:44] <bregma> it picks up its build results and builds on them
[23:44] <bregma> onyl things that depend on utouch-geis should have to be build tested
[23:45] <cnd> geis doesn't expose frame
[23:45] <cnd> so we don't actually need to worry about it
[23:45] <cnd> I mean, we don't need to worry about build failures for packages that depend on geis
[23:47] <cnd> ok, mtview built
[23:47] <cnd> I'll just double check utouch-grail and utouch-geis
[23:48] <cnd> cjwatson beat me to it
[23:52] <cnd> bregma, the last thing we need to do is determine what the state of lp:utouch-frame/ubuntu and lp:utouch-frame/precise is
[23:52] <cnd> which did you update when you released the package?
[23:53] <cnd> it looks like you released in ubuntu and merged it into precise?
[23:53] <cnd> if so, then we're probably fine
[23:54] <bregma> yes, that's what I did
[23:57] <bregma> the 'ubuntu' archives should be for ongoing work, the repo named after the release should be for patch releases only -- which only makes sense after final freeze
[23:57] <bregma> so prior to final freeze, the two should conceptually be identical
[23:57] <bregma> that was my reasoning