=== _salem is now known as salem_ === salem_ is now known as _salem === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [07:19] thomi: sil2100: hey! it seems that the QA stack is still not on shape, any news? https://jenkins.qa.ubuntu.com/job/ps-generic-autopilot-release-testing/443/testReport/ [07:24] didrocks: hello, I poked cyphermox about that yesterday, but since I was still busy with unity and the 100scopes, I'll simply take care of it today [07:24] sil2100: thanks, any news about Unity <-> 100 scopes, is it all fine? [07:24] didrocks: I've been actually also wondering if there is a threshold for the failures in QA? [07:25] sil2100: yeah, it's 0, they wanted everything to pass [07:26] sil2100: the other stacks were fine? only QA is blocking us? (I think HUD as well is blocking) [07:26] didrocks: the transition is fine, been just waiting for some autopilot results, now trying to actually get to jenkins [07:27] Can't seem to hm, load the page [07:27] didrocks: is it working for you? [07:27] sil2100: yeah, see #ubuntu-desktop [07:27] sil2100: seems like magners is dead [07:27] sil2100: I'm using the public jenkins for now to grab the results [07:27] Ah, right [07:27] sil2100: but some are more than 24h old [07:30] didrocks: checking the HUD stack now, it's 24h old, but still strange to see those failures, let me look into that - since both me and cyphermox fixed those in unity [07:30] sil2100: ah thanks :) [07:30] sil2100: so, you think that once QA/Hud dealt, basically, we'll have everything in next? [07:31] didrocks: yes, that should be the case, as the number of failures for unity should be a bit smaller now as well [07:31] *should* [07:31] As I need the latest AP results to make sure [07:32] sil2100: yep : [07:32] sil2100: ok, great, keep cracking on QA/Hud then :) === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [08:34] brb === mmrazik is now known as mmrazik|afk [09:09] didrocks, BTW about zeitgeist failure on a live session I filed bug 1181565, this is a regression in Saucy. Not sure it belongs to casper though [09:09] bug 1181565 in casper (Ubuntu) "wrong permissions on $HOME/.local/ on live session" [Undecided,New] https://launchpad.net/bugs/1181565 === mmrazik|afk is now known as mmrazik [09:44] didrocks, is there any way to get CI jobs on scopes branches that won't land in distro? (eg. server scopes) [09:58] jibel: thanks! [10:02] mzanetti: ping [10:08] davidcalle: ping [10:09] Is anyone having problems with unity and 13.04 and Nvidia drivers on 3.8+ kernel? [10:10] dednick: pong [10:12] mzanetti: hey. having some autopilot issues. dont know if you're the right person though. For indicators, I've subclassed a SwitchMenu object from the DBusIntrospectionObject class, but when i do a [for example] selct_single('SwitchMenu') i get an object back, but it doesnt seem that it's of the correct type. I can't call functions that i've declared on the subclassed type. [10:13] mzanetti: get this error - AttributeError: Class 'SwitchMenu' has no attribute 'get_checked' [10:14] dednick: you're not supposed to call frunction from an autopilot test [10:14] dednick: why would you need that? [10:14] mzanetti: it's an emulation in python. the get_checked was just a stub. [10:15] mzanetti: it was actually supposed to be a change_checked, which would move the mouse to the control and click. [10:16] dednick: can I see some code? [10:19] mzanetti: http://pastebin.ubuntu.com/5686511/ [10:22] dednick, ping [10:22] Saviq: pong [10:23] greyback, ping [10:24] Saviq: pong [10:24] dednick: you're not instantiating the SwitchMenu at all [10:25] dednick: auto_brightness is not of type SwitchMenu [10:25] mzanetti: it should be instantiated as that type by an internal autopilot [10:26] dednick: hmm... why is that? I'm not aware of such a feature [10:27] dednick: you could do the select_single() call inside the emulator (which is where it belongs anyways) and before returning it, wrap it yourself in that SwitchMenu class [10:27] mzanetti: well from what i understand in reading the code, each type that subclasses DBusIntrospectionObject is registed as a class type, which is instantiated against the one that was returned. [10:28] mzanetti: it's some pretty wacky python code, which i dont really understand. Might need to chat to thomi in this case. [10:29] dednick: yeah. haven't used such a thing yet. thomi might be your best bet here [10:29] mzanetti: ok thanks. thought you might have some across it in your AP wanderings [10:29] nope... sorry === mmrazik is now known as mmrazik|lunch [10:52] vesar: ping [10:52] mzanetti, hello sir. [10:53] vesar: hellp :) [10:53] s/p/o/ [10:53] vesar: I'd have some launcher awesomeness where I'd like to get some feedback [10:53] vesar: JohnLea said you would be the one to go to [10:53] mzanetti, brilliant. John already mentioned about it. [10:54] great! [10:54] mzanetti, happy to help. So you have some version of new launcher ready now? [10:55] vesar: lp:~mzanetti/unity/phablet-folding-launcher [10:55] Rebooting again [10:56] vesar: in LauncherShortcuts.qml there is a "inverted" propery you can set to invert it. [10:57] vesar: the Dash button is always there right now. No trash can right now. [10:57] mzanetti, cool. We'll give it a try. Any particular feedback you're looking for? [10:57] vesar: yes. the dragging [10:57] mzanetti, has reveal mode been removed? [10:58] vesar: no. its still there. [10:58] mzanetti, what do you mean by dragging. Dragging the icons to see the invisible icons and how the folding behaves? [10:59] vesar: yes. there are 2 ways of scrolling [10:59] vesar: afaics you named them ribbon mode and scroll mode or something like that [10:59] vesar: the normal flicking with the finger is still the same. [11:00] Damn [11:00] vesar: but the other one when dragging up/down directly while revewling behaves quite differently now. because the previous way with 2 areas at top/bottom didn't really work with the look&feel [11:00] vesar: just try it and you will see [11:01] mzanetti, ok. cool. thanks! and building is done using standard build scripts right? [11:01] vesar: yes [11:02] mzanetti, ok. we'll get back to you with comments soonish. [11:02] vesar: thanks === dandrader is now known as dandrader|afk [11:17] om26er, didrocks, Trevinho: would you guys mind if I got rid of the test_gedit_undo test in HUD ;)? [11:17] sil2100: is the test buggy? [11:18] didrocks: it's troublesome, and since it's there only for testing if application actions work, I made a bit simpler test for that [11:18] That's easier to assert without any static waits [11:19] mzanetti, mind giving what I've done of the infographics tests a review? [11:19] nic-doffay: sure. hit me [11:19] I'll finish those shaders by latest thursday for you. [11:19] mzanetti, it's pushed to the branch. [11:19] sil2100: if you have an equivalent simpler test, that's fine by me [11:19] sil2100: think about activate it for the hud stack then [11:21] Ok [11:22] nic-doffay: looks great! [11:22] mzanetti, ready to land after an additional animation then? [11:22] nic-doffay: the test_set_username() could again be done using a data() function. would make it a bit shorter, more flexible and more readable [11:24] mzanetti, yeah and the other one too. [11:24] Cool will get on to that. [11:24] vesar, you might need to ./build --clean (I did have to) mzanetti's branch [11:24] mzanetti, can you email me a branch of yours that you're working on which will need the shader and where it will be needed? === mmrazik|lunch is now known as mmrazik [11:25] nic-doffay: Dot.qml still has some indentation issues [11:25] Saviq: heh. what do you think? [11:26] mzanetti, only tried on desktop now, there was some jumpiness to it (and some errors on the console) [11:26] mzanetti, but good overall [11:26] Saviq: yes... looooots of errors because Launcher.qml still has all the scroll() code which does not exist in LauncherShortcuts.qml any more [11:27] Saviq: the jumpiness is during loading of lenses. it goes away after a few secs. [11:27] mzanetti, nah [11:27] mzanetti, what do you mean by indentation? [11:27] mzanetti, there seems to be some rounding involved (everything jumps up and down one pixel when scrolling) === dandrader|afk is now known as dandrader [11:27] Saviq: ah yeah... that one... true. [11:28] nic-doffay: its missing spaces before the closing braces at the bottom [11:28] mzanetti, and more perspective would be nice, but overall it's good [11:28] mzanetti, ah right [11:30] Saviq: I'll do those small time consuming tweaks once I know design is happy with the general direction [11:30] mzanetti, of course === hikiko is now known as hikiko_lunch === MacSlow is now known as MacSlow|lunch [11:55] Trevinho, andyrock, tsdgeos: ping [11:56] sil2100: just going for lunch, can it wait 50 min? [11:56] tsdgeos: yes ;) It's related to Unity 7.0 HUD, so not sure if you're into this anyway [11:59] sil2100, pong [11:59] i need to be afk for 5 mins [12:01] Saviq, this "tap outside to switch back from close mode" thing (app thumbnails in dash). Suppose I scroll to the bottom of Apps dash, where I'm looking at a bunch of icons (installed, available for download). What should happen when I tap on one of these icons? === hikiko_lunch is now known as hikiko [12:02] dandrader, good question, I'd say it should launch, and you should get out of close mode? [12:02] andyrock: ok, no problem === alan_g is now known as alan_g|lunch [12:05] Saviq, like when you flick horizontally towards another dash. I think this "tap outside to switchback from close mode" doesn't work because because the close mode is not a modal thing, like a popup of a launcher where you dim the UI behind it (a clear indication that tapping on dimmed controls won't activate them but dismiss the modal UI element instead) [12:05] s/of a launcher/or the launcher [12:06] Saviq, so the general idea would be instead: if you leave Apps dash (either by switching to another dash or launching an application) leave the close mode [12:07] dandrader, I'm afraid that's not a /me question [12:07] Saviq, well, you're the author of this task ;) [12:08] dandrader, I'm just a proxy ;) [12:08] dandrader, the current request we had is just "dismiss on tap outside of the running apps" [12:08] Saviq, ah! who asked for it? [12:08] dandrader, that was the original "designed" (not really) behaviour [12:08] dandrader, when (if?) we get more design around it, we'll get there [12:09] dandrader, pmcgowan pinged me about it recently [12:09] dandrader, truth is we might get rid of running apps altogether, in which case this particular usecase will be gone (but then you probably will be able to do the same on "Installed" apps to remove them) [12:11] sil2100, ok i'm ready [12:11] sil2100, what's up? [12:11] Saviq, hmm, then I should look for something else to invest my time on === jhodapp is now known as jhodapp|brb [12:14] dandrader, ok, put it to BLOCKED state and add a note in the whiteboard that this is pending design [12:15] andyrock: I noticed an HUD regression recently, I see now that it's probably on the 'backend' side, so I'll poke Ted later [12:15] But here's the bug: [12:15] sil2100, k [12:16] andyrock: https://jenkins.qa.ubuntu.com/job/ps-generic-autopilot-release-testing/436/label=autopilot-intel/testReport/unity.tests.test_hud/HudBehaviorTests/test_no_initial_values/ <- sometimes I also noticed that when opening the HUD, there are initial values in it [12:21] tsdgeos, do you have a branch where the ListView-based Carousel is re-reverted? there's a conflict that's not obvious to resolve at first look, maybe you did it already? [12:25] fginther: ping [12:25] fginther: once you're around, I have more HUD fixes [12:25] https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880 <- [12:25] bregma: maybe someone from your team could also take a look? ^ [12:25] bregma: since there are still some failures in the HUD tests, this should fix those [12:27] tsdgeos, nvm === jhodapp|brb is now known as jhodapp [12:29] sil2100: I don't know if its on your radar, but I've chatted with andyrock and co about the shortcuts overlay related failures [12:30] should be something about them soon [12:33] smspillaz, i think that failure is in lp:compiz/raring too [12:33] and it's not blocking IMHO [12:33] i'm happy with the current compiz trunk === MacSlow|lunch is now known as MacSlow [12:40] andyrock, smspillaz: which failures exactly? I made some AP tests fixes for those here: [12:41] https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702 [12:41] (it was supposed to be merged yesterday, but CI failed on one arch) [12:41] sil2100, unity.tests.test_shortcut_hint.ShortcutHintInteractionsTests.test_shortcut_hint_hide_pressing_modifiers [12:41] > [12:41] but it fails randomly [12:41] andyrock: ah, this one [12:42] Good! Would be nice to get that one out of the radar [12:53] andyrock: maybe you feel like doing some AP reviewing? ;) [12:53] Saviq: yes let me push [12:53] https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880 [12:53] Saviq: it's not very clean though [12:53] tsdgeos, got it already [12:53] sil2100, sure [12:53] Saviq: ok === _salem is now known as salem_ [12:58] andyrock: thanks! [13:00] sil2100: re: hud; unity didn't land all the changes, this is why hud was still not good [13:01] assuming the stuff landed this morning, the schedule makes it so that hud tests ran before the fixes landed === greyback is now known as greyback|food [13:02] sil2100: didrocks: is jenkins down? [13:02] cyphermox: yes [13:03] cyphermox: we're waiting for the US to reanimate [13:03] I may be able to help [13:03] cyphermox: indeed - I also made some additional changes to HUD tests, to all the stupid failures [13:03] The branch is being reviewed now [13:03] scratch that, my key passphrase was unlocked, but the server doesn't respond at all [13:03] * sil2100 sighs [13:03] linky? [13:04] https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880 [13:04] btw, I'm off today, just thought I'd give things a look to make sure hud and qa would be fixed [13:05] cyphermox: you shouldn't be connected then :) [13:05] cyphermox: run away! ;-) [13:05] figured people would ping me ;) [13:05] Ping pong ;) [13:05] No worries, if by any chance it's still not fixed, we'll be continuing to fix it up [13:14] andyrock: I think you should probably still add actions for and to make the behaviour determinisitc [13:14] *deterministic [13:14] smspillaz, we should but we don't need it to land compiz 0.9.10 [13:14] andyrock: yeah [13:14] andyrock: were there any other failures or are we all good ? [13:15] smspillaz, i'm good... but we need to land the new unity in S first of all [13:15] coolio [13:16] seems we may be a ways from landing Unity in S yet [13:16] heh [13:16] people are overenthusiastic about getting their breaking changes in early in the cycle [13:16] smspillaz: Man I hate you, now I've got to go find gangsters paradise [13:17] bregma: if you team gets some time, do you think I can get some reviews on some outstanding compiz branches? === alan_g|lunch is now known as alan_g [13:17] its a bit awkward to self-approve things [13:18] davmor2: not sure I get the reference, but I picked up the "coolio" thing from njpatel :p [13:18] smspillaz, I would like nothing more than to get that done, but I think people are loaded trying to get Unity landing... I'll bring it up, though [13:18] smspillaz: http://www.youtube.com/watch?v=YFK6H_CcuX8 [13:18] bregma: excellent, thanks [13:19] davmor2: haha [13:19] davmor2: this is exactly how I *dont* see myself :p [13:20] bregma: in the meantime, if I'm just adding tests for stuff, should I just self-merge stuff and have compiz treated more as an upstream ? [13:20] or is the preference to have more direct involvement [13:21] my only priority really is just to increase test coverage on the stuff that's easy to break without noticing. [13:22] smspillaz, I'd rather get at least one other set of eyes on every change, even if it's really trivial, just to make sure it really is really trivial [13:22] it may be pro forma, but.... [13:23] bregma: that's fine, although it needs to be timely in order to be workable === greyback|food is now known as greyback [13:24] yeah [13:24] let me know what we can come up with then :) [13:31] mzanetti, nic-doffay, standup [13:35] fginther: andyrock already reviewed the branch, so if you also say 'ok' I'll approve it globally: [13:35] https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880 [13:37] btw.! [13:37] fginther: are the mergers busy? [13:37] Since https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702 is waiting 1 hour already [13:37] sil2100, jenkins is having a bad day [13:38] Ah, ok ;) [13:39] sil2100, autopilot_fix_shortcut_and_scroll is building [13:40] \o/ [13:40] Thanks [13:43] greyback: just to make sure you're blocked on what I think you're blocked on :) [13:43] https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211 [13:43] is it that? [13:43] wrt shell-mir of course [13:44] kgunn: not even. I was told the platform-api would be changing, so the branches we were using to run shell would all need changing. [13:45] greyback: ah...even more awesome [13:45] :-/ [13:46] kgunn: also, the we've separate branches for server & client modes in both platform-api and qtubuntu. It's messy right now, they can't both be merged right now [13:47] kgunn: racarr has ideas on how to sort this, but was going to wait for the platform-api changes first [13:49] bregma: ping [13:50] dednick, what up? [13:50] bregma: howdy. i was wondering if you know if unity works with autopilot 1.3? [13:50] loaded question [13:50] the unity AP tests i mean [13:50] an in they run mostly ok. [13:51] ie it doesnt crash immediately ;) [13:51] I believe a few patches have gone in recently to make everything work, we're just waiting for them to land [13:51] but some recent 100-scopes merges crash still [13:53] dednick: we'll also know more once jenkins is up [13:58] Saviq: greyback & i just chatting about unity-mir layer, we're thinking it should be a seperate lp proj [13:58] thots? [13:58] kgunn, +1 [13:58] ok cool [13:58] kgunn, greyback, that's the conclusion from OAK, btw :) [13:59] kgunn, greyback, with the api defined in lp:unity-api [13:59] Saviq: i love it when the answer is already there [14:00] Saviq: of course...classic sprint question....was that decision before 3pm on Wed ? (substitute your desire time/day :) [14:00] Saviq: true. So my idea is for a very simple shell that Mir team can use to test their window management stuff. Where should that go? [14:00] Saviq: that api project? [14:01] greyback, I'd say the mir-qt project [14:02] kgunn, it was when we talked together with the Mir team, basically [14:02] Saviq: np, just kidding around [14:03] Saviq: so to calarify: unity-api for api definition and unit tests checking that api only. Integration tests live a bit higher up [14:04] greyback, yes [14:04] Saviq: ack [14:09] greyback: so back to the platform-api blocking i'm supposing this is it [14:09] https://code.launchpad.net/~robertcarr/platform-api/mir-client-and-server/+merge/163616 [14:13] kgunn: looks likely, yes. You had best confirm with racarr just to be sure, as I took him by his word. [14:14] kgunn: this could be the API change too: https://code.launchpad.net/~ricmm/platform-api/new_api_with_lifecycle/+merge/160691 [14:14] which is a big change too [14:15] cyphermox: still some failures for HUD, but I see that they're all the failures that I fixed with my branch [14:15] didrocks: ^ [14:17] sil2100: so, next run should be fixed? [14:17] greyback: ack [14:17] didrocks: once my branch will be merged in, yes [14:18] Checkin the QA stack now [14:19] didrocks, cyphermox: QA is also bugged, will try fixing that - if not I'll ask thomi for urgent help so that the nearest build be clear [14:19] sil2100: thanks [14:22] didrocks: the unity stack is also interesting - even though 10 hours ago all prepare jobs were successful, neither the check or build job was started for that run it seems [14:22] dandrader: Saviq as "next task" item, shouldn't we also do the work to build out indicator panel slide use the edge drag [14:22] with the added feature of sliding side to side to get the indicator options of course [14:22] didrocks: as all prepare jobs are finished successfully 10 hours ago, while both the build and check jobs ran 1d ago [14:22] sil2100: well, that's possible as there was the jenkins failure mid-way [14:22] didrocks: what could be the reason? [14:22] Ok [14:24] kgunn, doens't "sliding side to side to get the indicator options" conflict with the definition of a directional drag? [14:25] dandrader, not necessarily - the directional drag is the "main" / "master" gesture [14:25] dandrader: it has to at least start w directional [14:25] and then at some point pick it the side to side as a way to reveal the options [14:25] i would think [14:25] dandrader, the side movement is secondary (after the gesture was already classified as a directional one) [14:27] dandrader, btw, a similar trapezoid solution you used for actually recognizing a directional gesture needs to be implemented for switching between the indicators [14:27] Saviq, kgunn because it's different from the launcher case. In the Launcher you really drag from the screen edge, from nowhere. whereas in the panel case you have that status bar from where to start your gesture. so there no chance (or little) for conflict between panel drag vs. application intercation [14:27] i.e. the further down you go, it's "more difficult" to change the indicator === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [14:28] dandrader, sure, but the DDA supports that approach just fine, no? [14:28] dandrader, also, with full-screen apps the indicators go off screen [14:29] dandrader, and then the edge gesture is used to reveal them [14:29] sil2100, I get some intermittent test failures with your MP. I made a comment [14:31] fginther: thanks, looking! [14:32] fginther: this one, yes... I see this happening locally as well, and before on lp:unity as well [14:32] fginther: indeed we need to fix this somehow [14:33] fginther: hm, give me 30 minutes to try and fix it here, on this branch [14:33] If it will take longer, let's approve this branch as it is and prepare a separate branch for this failure [14:33] sil2100, cool. let me know if you have something to try, it fails frequently on my system [14:33] sil2100, I'll agree to that [14:33] fginther: jenkins had a problem with that lately as well from what I see... ;/ [14:34] Saviq, kgunn so that gets a higher priority than the "3rd party widgets in the dash" story? === seb128_ is now known as seb128 [14:34] dandrader, this would probably get used sooner (i.e. as soon as we implement it) ;) [14:37] dandrader, and the right edge gesture is more or less the same - i.e. Revealer should ultimately get replaced with DirectionalDragArea [14:38] fginther: in the meantime ;p https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702 still not merged ;( [14:42] sil2100, still building === dandrader is now known as dandrader|LUNCH === dandrader|LUNCH is now known as dandrader|lunch === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:26] hm, does anyone know if tedg will be online today? [15:27] sil2100: heard he is out all week [15:27] vacation [15:27] Ah, damn... [15:27] kgunn: thanks [15:27] kgunn: by any chance do you know who else is also responsible for the HUD backend? [15:30] sil2100: yeah...it really is just ted [15:30] i just checked with strehl [15:31] Thanks, eh ;) [15:31] sil2100: are you blocked? [15:31] might check with pete-woods if you are [15:32] kgunn: both Wellark and I are familiar with it === mmrazik is now known as mmrazik|afk [15:32] but not actively tasked with working on it [15:33] sil2100: ^ === jhodapp is now known as jhodapp|lunch [15:53] vesar: hey. I just pushed an updated version. Launching apps works again and the highlight labels are back. [15:55] nic-doffay: I've sent you the mail regarding the blurring [15:55] nic-doffay: is everything clear there? [15:57] mzanetti, haven't read through it yet, busy trying to get this shader to work on QML then I'll have a look! [15:58] nic-doffay: ok. I'll be off now and most likely only online again on thursday... [15:58] mzanetti, cool no prob! [16:04] fginther: I think I found a fix/workaround for that HUD issue [16:04] kgunn: thanks! [16:04] pete-woods: can I poke you in a few moments? [16:04] sil2100, awesomeness [16:05] sil2100: of course, I'll try and help if I can :) [16:09] mterry: ping [16:09] kgunn, heyo === dandrader|lunch is now known as dandrader [16:15] mzanetti, still there? [16:18] dandrader: yes [16:19] fginther: pushing the fix/workaround (since I'm not sure how to call that ;p) [16:20] mzanetti, do you know about the well-being of jenkins? [16:20] * mzanetti checks [16:21] mzanetti, its urls are not working: https://code.launchpad.net/~dandrader/unity/phablet_mouseTouchAdaptor/+merge/164870/comments/365052 [16:21] dandrader: it seems to be building stuff [16:22] dandrader: hmmm, true... seems public jenkins in a bad mood [16:22] dandrader: you can still reach the main instance tho [16:22] mzanetti, how can I check what failed in my build? [16:23] http://s-jenkins:8080/job/unity-phablet-ci/ [16:23] dandrader: ^ [16:23] dandrader: its the same build numbers as the internal one just syncs the exact result to the public instance [16:24] mzanetti, hmm, maybe it's just taking forever to publish results. some I'm able to reach the URl of an earlier failure [16:24] mzanetti, ok [16:25] mmrazik|afk: FYI: not sure if its a known issue already but publishing results seems to take too long again [16:29] mzanetti: mhm... === mmrazik|afk is now known as mmrazik [16:30] mzanetti: true... ~80 jobs in the queue atm [16:31] fginther: could you take a look? === jhodapp|lunch is now known as jhodapp [16:32] mzanetti, is autopilot capable of sending touch events? [16:32] dandrader: yes [16:32] dandrader: create a Finger device [16:33] mzanetti, cool. anyplace I should look at for an example or documentation? [16:33] dandrader: check the scenarios array and the setUp() [16:33] * dandrader never used autopilot before [16:33] dandrader: the current setup creates a scenario for desktop and one for the device [16:34] dandrader: the setUp() instantiates the stuff from the scenarios [16:34] dandrader: you can, however, manually always instantiate a Finger object in a certain test case [16:35] dandrader: so instead of useing self.pointing_device then you use self.my_finger_object in that certain test case [16:35] dandrader: autopilot is sweet [16:36] mzanetti, ok, thanks! [16:36] sil2100, I hope you're right! :) [16:36] dandrader: same if you want to force mouse usage. but be aware that on the desktop we can have Mouse and Finger, while on the device there's only Finger [16:37] dandrader: also you're entering somewhat new terrain here. I won't guarantee that everything works 100% as expected. [16:37] mzanetti, by the way, why to we have a desktop scenario if we have only tablet and phone uis so far? [16:37] tsdgeos: so for this one https://bugs.launchpad.net/touch-preview-images/+bug/1170550 [16:37] Launchpad bug 1170550 in touch-preview-images "Searching for people/music/video restarts the shell on manta" [Critical,Confirmed] [16:37] dandrader: because we want to run the tests on the desktop [16:37] we can say fix committed right? [16:38] mzanetti, the new Launcher, for instance, can be revealed only with touch unless mouse-to-touch conversion is enabled (for manual testing on a desktop) [16:38] kgunn: hmm, we can yeah, commited but not released because its still not in the "release ppa" [16:38] kgunn: Saviq was talking to Mirv this morning to get it in the "correct ppa" [16:38] not sure how that ended [16:39] dandrader: hmm... interesting.. Well the current scenarios mostly describe where the test runs [16:39] tsdgeos: exactly how its described...thanks [16:39] dandrader: but you need to have a play with those Finger and Mouse classes [16:39] mzanetti, ah, so a device scenario runs the test on an actual phone!? [16:39] dandrader: yes [16:39] wow [16:40] dandrader: as you can see, the desktop scenario tests all test cases multiple times with different form factors to simulate the devices [16:40] dandrader: the device scenario only runs them once in fullscreen [16:41] dandrader: if having troubles with Finger input on desktop, thomi should be able to help you. He'll be online in an hour two. [16:41] dandrader: I only used the Finger stuff on actual phone hardware so far [16:41] hmm, ok [16:41] dandrader: ah! make sure to chmod 666 /dev/input. The Finger objects needs write access to it [16:42] ok. have to leave now [16:42] hmm, so it actually creates a fake input device file. nice [16:42] yes [16:42] so one could record readings from a real gesture and play them back with the fake device [16:43] like the evemu tool [16:43] dandrader: yes. thats also an idea we've been talking about. but no real progress so far. input and ideas are welcome [16:43] mzanetti, do you know evemu? [16:43] dandrader: no [16:44] mzanetti, it's a family of tools for that. it was used in the utouch project [16:44] mzanetti, I pulled. I'm failing to launch apps. I think there is LauncherModel missing from the branch? Also label text is always "Camera" [16:44]