| 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:17 |
|---|---|---|
| Satoris | Earlier three fingers were always grabbed. Is this intentional? | 08:18 |
| Satoris | Also, if the window manipulation handles appear, the application still gets the touches. This is also different. | 08:31 |
| === tvoss|dinner is now known as tvoss | ||
| === tvoss is now known as tvoss|lunch | ||
| 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. | 11:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| Satoris | Apparently touch propagation is different depending on whether you consume XInput events from the virtual pointer or the device directly. | 12:26 |
| === tvoss|lunch is now known as tvoss | ||
| Satoris | Is Bluetooth pairing broken today? [ ] yes [ ] no [ ] only on some machines | 12:40 |
| === MacSlow|lunch is now known as MacSlow | ||
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| cnd | Satoris, yeah, but it's how xinput is supposed to work | 14:20 |
| Satoris | Ok. What about the continuation thingy? | 14:20 |
| bregma | I'm trying to run everything through valgrind today to make sure stuff is clean in that respect | 14:21 |
| 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:22 |
| cnd | hmm, actually, thinking some more | 14:23 |
| cnd | we may have to do it that way | 14:23 |
| 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:24 |
| 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:25 |
| Satoris | The correct behaviour is somewhere in the design team's brains. I have no idea what it is. | 14:26 |
| * 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:27 |
| Satoris | I hope he remembered to take his shotgun along. | 14:28 |
| cnd | oh right | 14:29 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| cnd | heh | 14:38 |
| 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:39 |
| 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:40 |
| Satoris | https://bugs.launchpad.net/launchpadlib/+bug/968952 | 14:41 |
| cnd | Satoris, we should be using arsenal | 14:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| Satoris | Which is the Correct and Supported Python library to use? Launchpadlib or the other one that Arsenal scripts use? | 14:46 |
| Satoris | All documentation that I see points to Launchpadlib.' | 14:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| cnd | and would allow devs to bookmark a url | 14:54 |
| Satoris | Yes. | 14:54 |
| 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:56 |
| 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:57 |
| Satoris | If yes, which one? | 14:58 |
| 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 | 14:59 |
| Satoris | Ok, I'll change it to use Arsenal tomorrow. | 15:00 |
| 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:01 |
| 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:02 |
| Satoris | Till tomorrow then. | 15:03 |
| 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:08 |
| tvoss | cnd, frame, grail and geis all need --enable-integration-tests? | 15:47 |
| bregma | they should, yes | 15:52 |
| tvoss | thanks | 15:53 |
| 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 | 15:58 |
| === tvoss is now known as tvoss|back_in_10 | ||
| === tvoss|back_in_10 is now known as tvoss | ||
| 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:19 |
| 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:20 |
| 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 | 18:21 |
| tvoss | cnd, dandrader you could propose manual tests in the mp :) | 19:31 |
| dandrader | tvoss, yeah, the last resort | 19:32 |
| cnd | yeah, I think that's the most straightforward | 19:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| lamalex | tvoss, it shouldn't be very hard to add support though | 19:40 |
| 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:41 |
| lamalex | tvoss, it's really, really, really simple | 19:42 |
| tvoss | lamalex, okay, any hints? :) | 19:42 |
| 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:43 |
| 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:44 |
| cnd | lamalex, have you guys looked into xorg-gtest by any chance? | 19:50 |
| 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:51 |
| lamalex | no, it's all python- it's based on the testtools/unittest | 19:54 |
| cnd | ok | 19:55 |
| 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:03 |
| lamalex | yup | 20:04 |
| lamalex | thats about right | 20:04 |
| lamalex | might want something like FourFingerDrag(x1, y1, x2, y2, path) | 20:04 |
| === popey_ is now known as popey | ||
| === Daviey_ is now known as Daviey | ||
| 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? | 20:31 |
| dandrader | ok, so I need to run unity/tools/autopilot and there's no longer a run_autopilot... | 21:02 |
| === dandrader is now known as dandrader|afk | ||
| cnd | oh bregma... | 23:25 |
| cnd | I forgot to tell you | 23:25 |
| 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:26 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| bregma | what was the information path through which you found out it required a FFe? | 23:38 |
| cnd | I asked on #ubuntu-devel | 23:38 |
| cnd | just cause I had a feeling it might be something that required it | 23:39 |
| 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:40 |
| cnd | yeah | 23:41 |
| cnd | I'm going to run pdebuild on the packages | 23:41 |
| bregma | you know I already did that before I uploladed utouch-geis | 23:43 |
| 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:44 |
| 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:45 |
| cnd | ok, mtview built | 23:47 |
| cnd | I'll just double check utouch-grail and utouch-geis | 23:47 |
| cnd | cjwatson beat me to it | 23:48 |
| 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:52 |
| cnd | it looks like you released in ubuntu and merged it into precise? | 23:53 |
| cnd | if so, then we're probably fine | 23:53 |
| bregma | yes, that's what I did | 23:54 |
| 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 | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!