[07:19] <didrocks> 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] <sil2100> 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] <didrocks> sil2100: thanks, any news about Unity <-> 100 scopes, is it all fine?
[07:24] <sil2100> didrocks: I've been actually also wondering if there is a threshold for the failures in QA?
[07:25] <didrocks> sil2100: yeah, it's 0, they wanted everything to pass
[07:26] <didrocks> sil2100: the other stacks were fine? only QA is blocking us? (I think HUD as well is blocking)
[07:26] <sil2100> didrocks: the transition is fine, been just waiting for some autopilot results, now trying to actually get to jenkins
[07:27] <sil2100> Can't seem to hm, load the page
[07:27] <sil2100> didrocks: is it working for you?
[07:27] <didrocks> sil2100: yeah, see #ubuntu-desktop
[07:27] <didrocks> sil2100: seems like magners is dead
[07:27] <didrocks> sil2100: I'm using the public jenkins for now to grab the results
[07:27] <sil2100> Ah, right
[07:27] <didrocks> sil2100: but some are more than 24h old
[07:30] <sil2100> 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] <didrocks> sil2100: ah thanks :)
[07:30] <didrocks> sil2100: so, you think that once QA/Hud dealt, basically, we'll have everything in next?
[07:31] <sil2100> didrocks: yes, that should be the case, as the number of failures for unity should be a bit smaller now as well
[07:31] <sil2100> *should*
[07:31] <sil2100> As I need the latest AP results to make sure
[07:32] <didrocks> sil2100: yep :
[07:32] <didrocks> sil2100: ok, great, keep cracking on QA/Hud then :)
[08:34] <sil2100> brb
[09:09] <jibel> 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:44] <davidcalle> didrocks, is there any way to get CI jobs on scopes branches that won't land in distro? (eg. server scopes)
[09:58] <didrocks> jibel: thanks!
[10:02] <dednick> mzanetti: ping
[10:08] <sil2100> davidcalle: ping
[10:09] <mirela666> Is anyone having problems with unity and 13.04 and Nvidia drivers on 3.8+ kernel?
[10:10] <mzanetti> dednick: pong
[10:12] <dednick> 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] <dednick> mzanetti: get this error - AttributeError: Class 'SwitchMenu' has no attribute 'get_checked'
[10:14] <mzanetti> dednick: you're not supposed to call frunction from an autopilot test
[10:14] <mzanetti> dednick: why would you need that?
[10:14] <dednick> mzanetti: it's an emulation in python. the get_checked was just a stub.
[10:15] <dednick> mzanetti: it was actually supposed to be a change_checked, which would move the mouse to the control and click.
[10:16] <mzanetti> dednick: can I see some code?
[10:19] <dednick> mzanetti: http://pastebin.ubuntu.com/5686511/
[10:22] <Saviq> dednick, ping
[10:22] <dednick> Saviq: pong
[10:23] <Saviq> greyback, ping
[10:24] <greyback> Saviq: pong
[10:24] <mzanetti> dednick: you're not instantiating the SwitchMenu at all
[10:25] <mzanetti> dednick: auto_brightness is not of type SwitchMenu
[10:25] <dednick> mzanetti: it should be instantiated as that type by an internal autopilot
[10:26] <mzanetti> dednick: hmm... why is that? I'm not aware of such a feature
[10:27] <mzanetti> 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] <dednick> 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] <dednick> mzanetti: it's some pretty wacky python code, which i dont really understand. Might need to chat to thomi in this case.
[10:29] <mzanetti> dednick: yeah. haven't used such a thing yet. thomi might be your best bet here
[10:29] <dednick> mzanetti: ok thanks. thought you might have some across it in your AP wanderings
[10:29] <mzanetti> nope... sorry
[10:52] <mzanetti> vesar: ping
[10:52] <vesar> mzanetti, hello sir.
[10:53] <mzanetti> vesar: hellp :)
[10:53] <mzanetti> s/p/o/
[10:53] <mzanetti> vesar: I'd have some launcher awesomeness where I'd like to get some feedback
[10:53] <mzanetti> vesar: JohnLea said you would be the one to go to
[10:53] <vesar> mzanetti, brilliant. John already mentioned about it.
[10:54] <mzanetti> great!
[10:54] <vesar> mzanetti, happy to help. So you have some version of new launcher ready now?
[10:55] <mzanetti> vesar: lp:~mzanetti/unity/phablet-folding-launcher
[10:55] <sil2100> Rebooting again
[10:56] <mzanetti> vesar: in LauncherShortcuts.qml there is a "inverted" propery you can set to invert it.
[10:57] <mzanetti> vesar: the Dash button is always there right now. No trash can right now.
[10:57] <vesar> mzanetti, cool. We'll give it a try. Any particular feedback you're looking for?
[10:57] <mzanetti> vesar: yes. the dragging
[10:57] <vesar> mzanetti, has reveal mode been removed?
[10:58] <mzanetti> vesar: no. its still there.
[10:58] <vesar> mzanetti, what do you mean by dragging. Dragging the icons to see the invisible icons and how the folding behaves?
[10:59] <mzanetti> vesar: yes. there are 2 ways of scrolling
[10:59] <mzanetti> vesar: afaics you named them ribbon mode and scroll mode or something like that
[10:59] <mzanetti> vesar: the normal flicking with the finger is still the same.
[11:00] <sil2100> Damn
[11:00] <mzanetti> 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] <mzanetti> vesar: just try it and you will see
[11:01] <vesar> mzanetti, ok. cool. thanks! and building is done using standard build scripts right?
[11:01] <mzanetti> vesar: yes
[11:02] <vesar> mzanetti, ok. we'll get back to you with comments soonish.
[11:02] <mzanetti> vesar: thanks
[11:17] <sil2100> om26er, didrocks, Trevinho: would you guys mind if I got rid of the test_gedit_undo test in HUD ;)?
[11:17] <didrocks> sil2100: is the test buggy?
[11:18] <sil2100> 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] <sil2100> That's easier to assert without any static waits
[11:19] <nic-doffay> mzanetti, mind giving what I've done of the infographics tests a review?
[11:19] <mzanetti> nic-doffay: sure. hit me
[11:19] <nic-doffay> I'll finish those shaders by latest thursday for you.
[11:19] <nic-doffay> mzanetti, it's pushed to the branch.
[11:19] <didrocks> sil2100: if you have an equivalent simpler test, that's fine by me
[11:19] <didrocks> sil2100: think about activate it for the hud stack then
[11:21] <sil2100> Ok
[11:22] <mzanetti> nic-doffay: looks great!
[11:22] <nic-doffay> mzanetti, ready to land after an additional animation then?
[11:22] <mzanetti> 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] <nic-doffay> mzanetti, yeah and the other one too.
[11:24] <nic-doffay> Cool will get on to that.
[11:24] <Saviq> vesar, you might need to ./build --clean (I did have to) mzanetti's branch
[11:24] <nic-doffay> 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?
[11:25] <mzanetti> nic-doffay: Dot.qml still has some indentation issues
[11:25] <mzanetti> Saviq: heh. what do you think?
[11:26] <Saviq> mzanetti, only tried on desktop now, there was some jumpiness to it (and some errors on the console)
[11:26] <Saviq> mzanetti, but good overall
[11:26] <mzanetti> 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] <mzanetti> Saviq: the jumpiness is during loading of lenses. it goes away after a few secs.
[11:27] <Saviq> mzanetti, nah
[11:27] <nic-doffay> mzanetti, what do you mean by indentation?
[11:27] <Saviq> mzanetti, there seems to be some rounding involved (everything jumps up and down one pixel when scrolling)
[11:27] <mzanetti> Saviq: ah yeah... that one... true.
[11:28] <mzanetti> nic-doffay: its missing spaces before the closing braces at the bottom
[11:28] <Saviq> mzanetti, and more perspective would be nice, but overall it's good
[11:28] <nic-doffay> mzanetti, ah right
[11:30] <mzanetti> Saviq: I'll do those small time consuming tweaks once I know design is happy with the general direction
[11:30] <Saviq> mzanetti, of course
[11:55] <sil2100> Trevinho, andyrock, tsdgeos: ping
[11:56] <tsdgeos> sil2100: just going for lunch, can it wait 50 min?
[11:56] <sil2100> tsdgeos: yes ;) It's related to Unity 7.0 HUD, so not sure if you're into this anyway
[11:59] <andyrock> sil2100, pong
[11:59] <andyrock> i need to be afk for 5 mins
[12:01] <dandrader> 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?
[12:02] <Saviq> dandrader, good question, I'd say it should launch, and you should get out of close mode?
[12:02] <sil2100> andyrock: ok, no problem
[12:05] <dandrader> 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] <dandrader> s/of a launcher/or the launcher
[12:06] <dandrader> 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] <Saviq> dandrader, I'm afraid that's not a /me question
[12:07] <dandrader> Saviq, well, you're the author of this task ;)
[12:08] <Saviq> dandrader, I'm just a proxy ;)
[12:08] <Saviq> dandrader, the current request we had is just "dismiss on tap outside of the running apps"
[12:08] <dandrader> Saviq, ah! who asked for it?
[12:08] <Saviq> dandrader, that was the original "designed" (not really) behaviour
[12:08] <Saviq> dandrader, when (if?) we get more design around it, we'll get there
[12:09] <Saviq> dandrader, pmcgowan pinged me about it recently
[12:09] <Saviq> 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] <andyrock> sil2100, ok i'm ready
[12:11] <andyrock> sil2100, what's up?
[12:11] <dandrader> Saviq, hmm, then I should look for something else to invest my time on
[12:14] <Saviq> dandrader, ok, put it to BLOCKED state and add a note in the whiteboard that this is pending design
[12:15] <sil2100> 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] <sil2100> But here's the bug:
[12:15] <andyrock> sil2100, k
[12:16] <sil2100> 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] <Saviq> 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] <sil2100> fginther: ping
[12:25] <sil2100> fginther: once you're around, I have more HUD fixes
[12:25] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880 <-
[12:25] <sil2100> bregma: maybe someone from your team could also take a look? ^
[12:25] <sil2100> bregma: since there are still some failures in the HUD tests, this should fix those
[12:27] <Saviq> tsdgeos, nvm
[12:29] <smspillaz> 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] <smspillaz> should be something about them soon
[12:33] <andyrock> smspillaz, i think that failure is in lp:compiz/raring too
[12:33] <andyrock> and it's not blocking IMHO
[12:33] <andyrock> i'm happy with the current compiz trunk
[12:40] <sil2100> andyrock, smspillaz: which failures exactly? I made some AP tests fixes for those here:
[12:41] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702
[12:41] <sil2100> (it was supposed to be merged yesterday, but CI failed on one arch)
[12:41] <andyrock> sil2100, unity.tests.test_shortcut_hint.ShortcutHintInteractionsTests.test_shortcut_hint_hide_pressing_modifiers
[12:41] <andyrock> >
[12:41] <andyrock> but it fails randomly
[12:41] <sil2100> andyrock: ah, this one
[12:42] <sil2100> Good! Would be nice to get that one out of the radar
[12:53] <sil2100> andyrock: maybe you feel like doing some AP reviewing? ;)
[12:53] <tsdgeos> Saviq: yes let me push
[12:53] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880
[12:53] <tsdgeos> Saviq: it's not very clean though
[12:53] <Saviq> tsdgeos, got it already
[12:53] <andyrock> sil2100, sure
[12:53] <tsdgeos> Saviq: ok
[12:58] <sil2100> andyrock: thanks!
[13:00] <cyphermox> sil2100: re: hud; unity didn't land all the changes, this is why hud was still not good
[13:01] <cyphermox> assuming the stuff landed this morning, the schedule makes it so that hud tests ran before the fixes landed
[13:02] <cyphermox> sil2100: didrocks: is jenkins down?
[13:02] <sil2100> cyphermox: yes
[13:03] <sil2100> cyphermox: we're waiting for the US to reanimate
[13:03] <cyphermox> I may be able to help
[13:03] <sil2100> cyphermox: indeed - I also made some additional changes to HUD tests, to all the stupid failures
[13:03] <sil2100> The branch is being reviewed now
[13:03] <cyphermox> scratch that, my key passphrase was unlocked, but the server doesn't respond at all
[13:03]  * sil2100 sighs
[13:03] <cyphermox> linky?
[13:04] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880
[13:04] <cyphermox> btw, I'm off today, just thought I'd give things a look to make sure hud and qa would be fixed
[13:05] <didrocks> cyphermox: you shouldn't be connected then :)
[13:05] <didrocks> cyphermox: run away! ;-)
[13:05] <cyphermox> figured people would ping me ;)
[13:05] <sil2100> Ping pong ;)
[13:05] <sil2100> No worries, if by any chance it's still not fixed, we'll be continuing to fix it up
[13:14] <smspillaz> andyrock: I think you should probably still add actions for <Control><Super> and <Shift><Super> to make the behaviour determinisitc
[13:14] <smspillaz> *deterministic
[13:14] <andyrock> smspillaz, we should but we don't need it to land compiz 0.9.10
[13:14] <smspillaz> andyrock: yeah
[13:14] <smspillaz> andyrock: were there any other failures or are we all good ?
[13:15] <andyrock> smspillaz, i'm good... but we need to land the new unity  in S first of all
[13:15] <smspillaz> coolio
[13:16] <bregma> seems we may be a ways from landing Unity in S yet
[13:16] <smspillaz> heh
[13:16] <bregma> people are overenthusiastic about getting their breaking changes in early in the cycle
[13:16] <davmor2> smspillaz: Man I hate you, now I've got to go find gangsters paradise
[13:17] <smspillaz> bregma: if you team gets some time, do you think I can get some reviews on some outstanding compiz branches?
[13:17] <smspillaz> its a bit awkward to self-approve things
[13:18] <smspillaz> davmor2: not sure I get the reference, but I picked up the "coolio" thing from njpatel :p
[13:18] <bregma> 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] <davmor2> smspillaz: http://www.youtube.com/watch?v=YFK6H_CcuX8
[13:18] <smspillaz> bregma: excellent, thanks
[13:19] <smspillaz> davmor2: haha
[13:19] <smspillaz> davmor2: this is exactly how I *dont* see myself :p
[13:20] <smspillaz> 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] <smspillaz> or is the preference to have more direct involvement
[13:21] <smspillaz> my only priority really is just to increase test coverage on the stuff that's easy to break without noticing.
[13:22] <bregma> 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] <bregma> it may be pro forma, but....
[13:23] <smspillaz> bregma: that's fine, although it needs to be timely in order to be workable
[13:24] <bregma> yeah
[13:24] <smspillaz> let me know what we can come up with then :)
[13:31] <Saviq> mzanetti, nic-doffay, standup
[13:35] <sil2100> fginther: andyrock already reviewed the branch, so if you also say 'ok' I'll approve it globally:
[13:35] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_hud_more_fixes/+merge/164880
[13:37] <sil2100> btw.!
[13:37] <sil2100> fginther: are the mergers busy?
[13:37] <sil2100> Since https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702 is waiting 1 hour already
[13:37] <fginther> sil2100, jenkins is having a bad day
[13:38] <sil2100> Ah, ok ;)
[13:39] <fginther> sil2100, autopilot_fix_shortcut_and_scroll is building
[13:40] <sil2100> \o/
[13:40] <sil2100> Thanks
[13:43] <kgunn> greyback: just to make sure you're blocked on what I think you're blocked on :)
[13:43] <kgunn> https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211
[13:43] <kgunn> is it that?
[13:43] <kgunn> wrt shell-mir of course
[13:44] <greyback> 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] <kgunn> greyback: ah...even more awesome
[13:45] <kgunn> :-/
[13:46] <greyback> 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] <greyback> kgunn: racarr has ideas on how to sort this, but was going to wait for the platform-api changes first
[13:49] <dednick> bregma: ping
[13:50] <bregma> dednick, what up?
[13:50] <dednick> bregma: howdy. i was wondering if you know if unity works with autopilot 1.3?
[13:50] <bregma> loaded question
[13:50] <dednick> the unity AP tests i mean
[13:50] <dednick> an in they run mostly ok.
[13:51] <dednick> ie it doesnt crash immediately ;)
[13:51] <bregma> I believe a few patches have gone in recently to make everything work, we're just waiting for them to land
[13:51] <bregma> but some recent 100-scopes merges crash still
[13:53] <sil2100> dednick: we'll also know more once jenkins is up
[13:58] <kgunn> Saviq: greyback & i just chatting about unity-mir layer, we're thinking it should be a seperate lp proj
[13:58] <kgunn> thots?
[13:58] <Saviq> kgunn, +1
[13:58] <greyback> ok cool
[13:58] <Saviq> kgunn, greyback, that's the conclusion from OAK, btw :)
[13:59] <Saviq> kgunn, greyback, with the api defined in lp:unity-api
[13:59] <kgunn> Saviq: i love it when the answer is already there
[14:00] <kgunn> Saviq: of course...classic sprint question....was that decision before 3pm on Wed ? (substitute your desire time/day :)
[14:00] <greyback> 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] <greyback> Saviq: that api project?
[14:01] <Saviq> greyback, I'd say the mir-qt project
[14:02] <Saviq> kgunn, it was when we talked together with the Mir team, basically
[14:02] <kgunn> Saviq: np, just kidding around
[14:03] <greyback> 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] <Saviq> greyback, yes
[14:04] <greyback> Saviq: ack
[14:09] <kgunn> greyback: so back to the platform-api blocking i'm supposing this is it
[14:09] <kgunn> https://code.launchpad.net/~robertcarr/platform-api/mir-client-and-server/+merge/163616
[14:13] <greyback> kgunn: looks likely, yes. You had best confirm with racarr just to be sure, as I took him by his word.
[14:14] <greyback> kgunn: this could be the API change too: https://code.launchpad.net/~ricmm/platform-api/new_api_with_lifecycle/+merge/160691
[14:14] <greyback> which is a big change too
[14:15] <sil2100> cyphermox: still some failures for HUD, but I see that they're all the failures that I fixed with my branch
[14:15] <sil2100> didrocks: ^
[14:17] <didrocks> sil2100: so, next run should be fixed?
[14:17] <kgunn> greyback: ack
[14:17] <sil2100> didrocks: once my branch will be merged in, yes
[14:18] <sil2100> Checkin the QA stack now
[14:19] <sil2100> 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] <didrocks> sil2100: thanks
[14:22] <sil2100> 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] <kgunn> 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] <kgunn> with the added feature of sliding side to side to get the indicator options of course
[14:22] <sil2100> didrocks: as all prepare jobs are finished successfully 10 hours ago, while both the build and check jobs ran 1d ago
[14:22] <didrocks> sil2100: well, that's possible as there was the jenkins failure mid-way
[14:22] <sil2100> didrocks: what could be the reason?
[14:22] <sil2100> Ok
[14:24] <dandrader> kgunn, doens't "sliding side to side to get the indicator options" conflict with the definition of a directional drag?
[14:25] <Saviq> dandrader, not necessarily - the directional drag is the "main" / "master" gesture
[14:25] <kgunn> dandrader: it has to at least start w directional
[14:25] <kgunn> and then at some point pick it the side to side as a way to reveal the options
[14:25] <kgunn> i would think
[14:25] <Saviq> dandrader, the side movement is secondary (after the gesture was already classified as a directional one)
[14:27] <Saviq> 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] <dandrader> 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] <Saviq> i.e. the further down you go, it's "more difficult" to change the indicator
[14:28] <Saviq> dandrader, sure, but the DDA supports that approach just fine, no?
[14:28] <Saviq> dandrader, also, with full-screen apps the indicators go off screen
[14:29] <Saviq> dandrader, and then the edge gesture is used to reveal them
[14:29] <fginther> sil2100, I get some intermittent test failures with your MP. I made a comment
[14:31] <sil2100> fginther: thanks, looking!
[14:32] <sil2100> fginther: this one, yes... I see this happening locally as well, and before on lp:unity as well
[14:32] <sil2100> fginther: indeed we need to fix this somehow
[14:33] <sil2100> fginther: hm, give me 30 minutes to try and fix it here, on this branch
[14:33] <sil2100> If it will take longer, let's approve this branch as it is and prepare a separate branch for this failure
[14:33] <fginther> sil2100, cool. let me know if you have something to try, it fails frequently on my system
[14:33] <fginther> sil2100, I'll agree to that
[14:33] <sil2100> fginther: jenkins had a problem with that lately as well from what I see... ;/
[14:34] <dandrader> Saviq, kgunn so that gets a higher priority than the "3rd party widgets in the dash" story?
[14:34] <Saviq> dandrader, this would probably get used sooner (i.e. as soon as we implement it) ;)
[14:37] <Saviq> dandrader, and the right edge gesture is more or less the same - i.e. Revealer should ultimately get replaced with DirectionalDragArea
[14:38] <sil2100> fginther: in the meantime ;p https://code.launchpad.net/~sil2100/unity/autopilot_fix_shortcut_and_scroll/+merge/164702 still not merged ;(
[14:42] <fginther> sil2100, still building
[15:26] <sil2100> hm, does anyone know if tedg will be online today?
[15:27] <kgunn> sil2100: heard he is out all week
[15:27] <kgunn> vacation
[15:27] <sil2100> Ah, damn...
[15:27] <sil2100> kgunn: thanks
[15:27] <sil2100> kgunn: by any chance do you know who else is also responsible for the HUD backend?
[15:30] <kgunn> sil2100: yeah...it really is just ted
[15:30] <kgunn> i just checked with strehl
[15:31] <sil2100> Thanks, eh ;)
[15:31] <kgunn> sil2100: are you blocked?
[15:31] <kgunn> might check with pete-woods if you are
[15:32] <pete-woods> kgunn: both Wellark and I are familiar with it
[15:32] <pete-woods> but not actively tasked with working on it
[15:33] <kgunn> sil2100: ^
[15:53] <mzanetti> vesar: hey. I just pushed an updated version. Launching apps works again and the highlight labels are back.
[15:55] <mzanetti> nic-doffay: I've sent you the mail regarding the blurring
[15:55] <mzanetti> nic-doffay: is everything clear there?
[15:57] <nic-doffay> 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] <mzanetti> nic-doffay: ok. I'll be off now and most likely only online again on thursday...
[15:58] <nic-doffay> mzanetti, cool no prob!
[16:04] <sil2100> fginther: I think I found a fix/workaround for that HUD issue
[16:04] <sil2100> kgunn: thanks!
[16:04] <sil2100> pete-woods: can I poke you in a few moments?
[16:04] <fginther> sil2100, awesomeness
[16:05] <pete-woods> sil2100: of course, I'll try and help if I can :)
[16:09] <kgunn> mterry: ping
[16:09] <mterry> kgunn, heyo
[16:15] <dandrader> mzanetti, still there?
[16:18] <mzanetti> dandrader: yes
[16:19] <sil2100> fginther: pushing the fix/workaround (since I'm not sure how to call that ;p)
[16:20] <dandrader> mzanetti, do you know about the well-being of jenkins?
[16:20]  * mzanetti checks
[16:21] <dandrader> mzanetti, its urls are not working: https://code.launchpad.net/~dandrader/unity/phablet_mouseTouchAdaptor/+merge/164870/comments/365052
[16:21] <mzanetti> dandrader: it seems to be building stuff
[16:22] <mzanetti> dandrader: hmmm, true... seems public jenkins in a bad mood
[16:22] <mzanetti> dandrader: you can still reach the main instance tho
[16:22] <dandrader> mzanetti, how can I check what failed in my build?
[16:23] <mzanetti> http://s-jenkins:8080/job/unity-phablet-ci/
[16:23] <mzanetti> dandrader: ^
[16:23] <mzanetti> dandrader: its the same build numbers as the internal one just syncs the exact result to the public instance
[16:24] <dandrader> 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] <dandrader> mzanetti, ok
[16:25] <mzanetti> mmrazik|afk: FYI: not sure if its a known issue already but publishing results seems to take too long again
[16:29] <mmrazik|afk> mzanetti: mhm...
[16:30] <mmrazik> mzanetti: true... ~80 jobs in the queue atm
[16:31] <sil2100> fginther: could you take a look?
[16:32] <dandrader> mzanetti, is autopilot capable of sending touch events?
[16:32] <mzanetti> dandrader: yes
[16:32] <mzanetti> dandrader: create a Finger device
[16:33] <dandrader> mzanetti, cool. anyplace I should look at for an example or documentation?
[16:33] <mzanetti> dandrader: check the scenarios array and the setUp()
[16:33]  * dandrader never used autopilot before
[16:33] <mzanetti> dandrader: the current setup creates a scenario for desktop and one for the device
[16:34] <mzanetti> dandrader: the setUp() instantiates the stuff from the scenarios
[16:34] <mzanetti> dandrader: you can, however, manually always instantiate a Finger object in a certain test case
[16:35] <mzanetti> dandrader: so instead of useing self.pointing_device then you use self.my_finger_object in that certain test case
[16:35] <sil2100> dandrader: autopilot is sweet
[16:36] <dandrader> mzanetti, ok, thanks!
[16:36] <dandrader> sil2100, I hope you're right! :)
[16:36] <mzanetti> 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] <mzanetti> dandrader: also you're entering somewhat new terrain here. I won't guarantee that everything works 100% as expected.
[16:37] <dandrader> mzanetti, by the way, why to we have  a desktop scenario if we have only tablet and phone uis so far?
[16:37] <kgunn> tsdgeos: so for this one https://bugs.launchpad.net/touch-preview-images/+bug/1170550
[16:37] <mzanetti> dandrader: because we want to run the tests on the desktop
[16:37] <kgunn> we can say fix committed right?
[16:38] <dandrader> 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] <tsdgeos> kgunn: hmm, we can yeah, commited but not released because its still not in the "release ppa"
[16:38] <tsdgeos> kgunn: Saviq was talking to Mirv this morning to get it in the "correct ppa"
[16:38] <tsdgeos> not sure how that ended
[16:39] <mzanetti> dandrader: hmm... interesting.. Well the current scenarios mostly describe where the test runs
[16:39] <kgunn> tsdgeos: exactly how its described...thanks
[16:39] <mzanetti> dandrader: but you need to have a play with those Finger and Mouse classes
[16:39] <dandrader> mzanetti, ah, so a device scenario runs the test on an actual phone!?
[16:39] <mzanetti> dandrader: yes
[16:39] <dandrader> wow
[16:40] <mzanetti> dandrader: as you can see, the desktop scenario tests all test cases multiple times with different form factors to simulate the devices
[16:40] <mzanetti> dandrader: the device scenario only runs them once in fullscreen
[16:41] <mzanetti> 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] <mzanetti> dandrader: I only used the Finger stuff on actual phone hardware so far
[16:41] <dandrader> hmm, ok
[16:41] <mzanetti> dandrader: ah! make sure to chmod 666 /dev/input. The Finger objects needs write access to it
[16:42] <mzanetti> ok. have to leave now
[16:42] <dandrader> hmm, so it actually creates a fake input device file. nice
[16:42] <mzanetti> yes
[16:42] <dandrader> so one could record readings from a real gesture and play them back with the fake device
[16:43] <dandrader> like the evemu tool
[16:43] <mzanetti> dandrader: yes. thats also an idea we've been talking about. but no real progress so far. input and ideas are welcome
[16:43] <dandrader> mzanetti, do you know evemu?
[16:43] <mzanetti> dandrader: no
[16:44] <dandrader> mzanetti, it's a family of tools for that. it was used in the utouch project
[16:44] <vesar> 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] <dandrader> you can record a gesture and then create a fake device and play it back through it
[16:44] <mzanetti> dandrader: you actually can launch binaries from within a test case. So you most likely are already able to use it
[16:44] <mzanetti> vesar: let me check if I pushed everything
[16:45] <mzanetti> vesar: yes, I did. Did you rebuild?
[16:45] <mzanetti> vesar: the fake model is now in C++, not QML any more
[16:45] <dandrader> mzanetti, package is evemu-tools
[16:45] <mzanetti> vesar: plugins/unity/launcher
[16:45] <vesar> mzanetti, oh I didn't. I see. Ok. sorry for that.
[16:45] <mzanetti> vesar: no worries
[16:47] <mzanetti> dandrader: ok... really off now. Looking forward to see your findings on thursday
[16:47] <dandrader> mzanetti, ok, thanks!
[16:47] <mzanetti> bye
[16:55]  * greyback eod
[16:56] <sil2100> pete-woods: hi! Are you still around?
[16:56] <pete-woods> sil2100: hi, yes!
[16:56] <sil2100> pete-woods: I want to ask about something, since I noticed the new HUD having a really irritating issue (regression)
[16:57] <pete-woods> okay
[16:57] <sil2100> pete-woods: sometimes after using the hud for a few times, hud-service starts hogging resources and slows down the whole system
[16:57] <sil2100> Is that a known issue?
[16:57] <pete-woods> so I could speculate
[16:57] <pete-woods> each time you connect to HUD, it creates a new dbus resource, and an associated query object
[16:58] <pete-woods> this object is reasonably heavyweight, because it brings voice recognition with it
[16:58] <pete-woods> so if somehow, there is a bug that causes this object not to be freed
[16:58] <pete-woods> you will end up with a huge leak
[16:58] <pete-woods> I've seen it happen before
[16:58] <pete-woods> but we fixed the bug that time, as far as I know
[16:58] <sil2100> pete-woods: ah, so it seems it's all caused by one root cause then, since the heavyweight-issue already causes slowdowns of action executions it seems
[16:59] <vesar> mzanetti, It looks like now it's almost impossible to bring the launcher in (ribbon mode) without launching an app and hiding the launcher again.
[16:59] <sil2100> pete-woods: since I'm using the latest HUD today and it's really happening often, I'm killing hud-service quite often when running autopilot tests
[16:59] <sil2100> pete-woods: it's slowing down the system so much that even the HUD is appearing so slow that it's not usable
[16:59] <sil2100> Same for applications being spawned, takes forever
[17:00] <vesar> mzanetti, I think something's a bit broken in Launcher.qml logic
[17:00] <pete-woods> sil2100: that might explain it - if you don't disconnect cleanly from HUD, it could potentially leave this query object alive
[17:00] <pete-woods> it's supposed to handle that (as I mentioned earlier)
[17:01] <sil2100> pete-woods: thanks for the explaination! I'll fill in a bug about this then, since it might be a reappearence of an old bug
[17:01] <pete-woods> you could possibly work around it by ensuring the autopilot tests don't leave HUD hanging
[17:02] <pete-woods> really, even with this bug, the leak shouldn't happen, because the shell should be closing the query object on shutdown
[17:02] <pete-woods> so I'd say there's probably a bug on both ends there
[17:02] <vesar> mzanetti, bur sorry I need to go for today but can help you with that tomorrow if needed. Anyway have to say that I like the way it folds the icons currently and keeps all the icons visible currently. We are currently a bit short with designer resources but will look into that more tomorrow.
[17:02] <sil2100> pete-woods: that makes sense
[17:04] <pete-woods> sil2100: see http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/view/head:/data/com.canonical.hud.query.xml
[17:04] <pete-woods> the CloseQuery method should be called when the shell shuts down
[17:06] <pete-woods> although, actually, as you're using the client library, it should be enough to dispose the query object you get from: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/view/head:/libhud-client/query.h
[17:30] <dandrader> tsdgeos, ping
[17:30] <tsdgeos> dandrader: sup
[17:30] <dandrader> tsdgeos, how do I run those autopilot tests?
[17:31] <tsdgeos> autopilot run qml_phone_shell
[17:31] <tsdgeos> in tests/autopilot
[17:33] <dandrader> tsdgeos, "ImportError: No module named platform"
[17:33] <tsdgeos> do you have this? http://paste.kde.org/~tsdgeos/748238/
[17:35] <dandrader> tsdgeos, you're getting your autopilot packages from a ppa?
[17:35] <tsdgeos> maybe
[17:35] <tsdgeos> not sure if it's needed
[17:35] <tsdgeos> do you have at least all the packages installed?
[17:35] <tsdgeos> # Autopilot
[17:35] <tsdgeos> deb http://ppa.launchpad.net/autopilot/ppa/ubuntu raring main
[17:35] <tsdgeos> deb-src http://ppa.launchpad.net/autopilot/ppa/ubuntu raring main
[17:35] <tsdgeos> that's the ppa i have
[17:36] <dandrader> tsdgeos, there's no autopilot-desktop in raring
[17:36] <tsdgeos> i see
[17:36] <tsdgeos> then you probably need the ppa
[21:41] <dednick> thomi: ping
[21:41] <thomi> dednick: in a call, 2 mins
[21:44] <thomi> dednick: hit me
[21:44] <dednick> thomi: hey. you get my email?
[21:45] <thomi> dednick: yes, I'm trying to think of a clever way to solve it
[21:45] <dednick> thomi: ok cool. just wanted to check if you got what i was talking about
[21:45] <thomi> dednick: it's an awkward case - on the one hand you don't want to launch the shell from within autopilot, on the other hand you don't want to listen at a known dbus location :-/
[21:45] <thomi> trust those pesky shell developers to be difficult :P
[21:46] <dednick> thomi: yeah, it's a bit of a pain.
[21:47] <thomi> dednick: how necessary is it that you define your own emulators?
[21:48] <dednick> thomi: right now, not massively, but i'm pretty sure it'll be necessary
[21:48] <thomi> hmmm
[21:48] <dednick> soon
[21:49] <thomi> ok, I'll come up with something. I can probably do something sneaky with the DBusIntrospectionObject metaclass
[21:49] <dednick> thomi: why are types dependant on the backend?
[21:50] <thomi> dednick: because they need to know where to get their data from
[21:50] <thomi> dednick: we already delay the construction of the actual communication over DBus until you instantiate one of those classes, but that's not enough
[21:51] <thomi> since, as you point out, you still need the address info at import time
[21:52] <dednick> thomi: any way to refresh the import dynamically?
[21:52] <dednick> thomi: eh. i dont know enough about python to say anything useful :)
[21:52] <thomi> dednick: not really. There are hacky solutions, but they're a really really bad idea
[21:53] <thomi> I'll hack something together and email you before EOD
[21:53] <dednick> thomi: cool. thanks
[21:53] <thomi> nw
[21:53] <dednick> thomi: ok, i'm off to bed. have a good day.
[21:54] <thomi> you too, errr...
[21:54] <dednick> thomi: when are you coming over btw?
[21:54] <thomi> dednick: I leave on the 10th
[21:54] <thomi> dednick: over there for almost 2 weeks
[21:54] <dednick> thomi: cool. Neil's stag this Saturday.
[21:54] <thomi> awww, pity I'll miss that
[21:54] <dednick> thomi: 2. ah, thats awesome.
[21:56] <dednick> thomi: i'm off. cya
[21:56] <thomi> laters