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