[00:14] <tigrang> How do I run the unit tests? I was told './test/test-getst' but there is no file like that
[00:15] <tigrang> I lied
[00:15] <bschaefer> tigrang, well where are you in the direction?
[00:15] <bschaefer> directory*
[00:15] <bschaefer> (should be in unity/build/tests/test-gtest
[00:15] <bschaefer> )
[00:15] <tigrang> was looking in tests/ directory, but it's inside build/tests
[00:15] <bschaefer> yup!
[00:15] <tigrang> yea, my bad, thanks
[00:16] <bschaefer> no worries, I still get confused when I want to open a source file while in build/tests :)
[00:16] <bschaefer> but have to go ../../tests
[01:21] <cyphermox> bschaefer: still around?
[01:22] <bschaefer> cyphase, yup, hello
[01:22] <cyphermox> hehe
[01:22] <cyphermox> hello ;)
[01:22] <cyphase> lol
[01:22] <bschaefer> opps
[01:22] <bschaefer> cyphase, sorry!
[01:22] <cyphase> no problem, happens all the time
[01:22] <cyphermox> do you have time to do a quick review for autopilot-qt?
[01:22] <bschaefer> 4 chars overlap!
[01:22] <cyphermox> https://code.launchpad.net/~mathieu-tl/autopilot-qt/arches/+merge/154567
[01:22] <bschaefer> cyphermox, yeah I can take a look hopefully
[01:22] <cyphase> i should change to cyphzse :)
[01:23] <cyphermox> cyphase: nice :P
[01:23] <bschaefer> cyphermox, what is any declared? (Just want to make sure powerpc is the only thing missing from the list)
[01:24] <cyphermox> bschaefer: any actually includes powerpc
[01:24] <bschaefer> s/what/where*
[01:24] <cyphermox> (which is what we don't want)
[01:24] <bschaefer> cyphermox, yeah, so the list is 5?
[01:24] <cyphermox> that's subject from interpretation based on what distro builder supports
[01:24]  * bschaefer just wants to double check non are missing
[01:24] <cyphermox> on Ubuntu, yes
[01:24] <bschaefer> oo alright
[01:24] <bschaefer> cool looks good to me then
[01:24] <cyphermox> on Debian it's more like 15 or so ;)
[01:25] <bschaefer> haha, approved :)
[01:25] <cyphermox> this is just temporary to unblock autopilot-qt
[01:25] <cyphermox> thanks!
[01:25] <bschaefer> cyphermox, cool, I figure once its fixed it'll go back to any :)
[01:25] <bschaefer> np!
[01:25] <cyphermox> yup
[01:58] <tigrang> Is there anything wrong with this (in terms of coding standards/style or stuff I shouldn't be using)? https://gist.github.com/tigrang/6af395688f7f782a0a92 (6 lines)
[02:06] <bschaefer> tigrang, looks fine to me. Looks like the surrounding code.
[02:10] <tigrang> ok, thanks for taking a look
[08:19] <tsdgeos> mzanetti: ran https://code.launchpad.net/~aacid/unity/giveNexus10TestMoreTimeToStart/+merge/154458 4 times on CI and didn't get any "36 seconds of nothing", seems it may be "a fix" since i'd say it was happening more than 25%
[08:20] <mzanetti> tsdgeos: ack
[08:20] <mzanetti> tsdgeos: thanks. I'll read it and approve if there aren't any bad thing in the code
[08:21] <mzanetti> looks fine
[08:22] <tsdgeos> mzanetti: and we need https://code.launchpad.net/~aacid/unity/fix_hud_test_stubborness/+merge/154446 too
[08:22] <tsdgeos> i had one of the tests need the retry
[08:22] <tsdgeos> and then it failed becuse of the missing return :D
[08:31] <mzanetti> tsdgeos: right... approved...
[08:49] <tsdgeos> MacSlow: mzanetti: Saviq: what about https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416 ?
[08:49] <MacSlow> tsdgeos, looking...
[08:50] <mzanetti> tsdgeos: we can remove it if its not needed, yes. I guess it will be needed at some point tho...
[08:51] <MacSlow> tsdgeos, btw... what's wrong with that function?
[08:51] <tsdgeos> MacSlow: unused
[08:51] <MacSlow> tsdgeos, but how does the Dash get activated then... (asking because me still being new to QML)
[08:52] <tsdgeos> mzanetti: not sure, we are already "showing the dash" when showing the launcher, or when clicking in the dash button, so obviously we know how to do it in a different way
[08:52] <tsdgeos> MacSlow: it's connected somewhere else
[08:52] <mzanetti> tsdgeos: I guess this is more for the desktop szenario where the whole thing is hidden
[08:53] <mzanetti> tsdgeos: not about switching to the home lens
[08:53] <tsdgeos> mzanetti: sure, that may be needed by then
[08:53] <mzanetti> yeah. thats what I meant.... well. don't have a strong opinion on it
[08:54] <MacSlow> tsdgeos, I'd be ok with removing it
[08:54] <tsdgeos> i just suggest removeing because i was looking at how the dash works in a general way yesterday
[08:54] <tsdgeos> and having a function that does nothing kept bugging me
[08:55] <mzanetti> ack... fine with it too...
[08:55] <mzanetti> tsdgeos: Iirc yesterday you asked what a "colocated" branch is
[08:55] <tsdgeos> mzanetti: yep, Saviq answered
[08:55] <mzanetti> tsdgeos: ah. mind repeating the answer for me? I missed that one
[08:55] <Saviq> mzanetti, what git does
[08:56] <Saviq> mzanetti, so that you go "bzr switch some_branch"
[08:56] <Saviq> mzanetti, and it checks out that branch to your working dir
[08:56] <Saviq> while keeping the bare repos in .bzr/branches
[08:56] <mzanetti> wait...
[08:56] <mzanetti> thats possible?
[08:56] <Saviq> mzanetti, `bzr colo-ify`
[08:56] <tsdgeos> Saviq: what's your stance on removing this function https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416
[08:56] <mzanetti> was my first question when I joined canonocal
[08:56] <Saviq> tsdgeos, +1
[08:56] <mzanetti> asked the wrong people then
[08:57] <MacSlow> tsdgeos, approved it
[08:57] <Saviq> mzanetti, it's not the best, but more or less works
[08:57] <Saviq> but you can't move/rename the dir after <facepalm>
[08:57] <Saviq> it keeps full paths to the bare repos
[08:58] <mzanetti> right... thanks. I'll see if I can make the hook work with it
[08:58] <Saviq> mzanetti, it's a slap-on, unfortunately
[09:00] <tsdgeos> mzanetti: btw i'm not using colocated branches and the hook doesn't seem to work for me either
[09:00] <mzanetti> tsdgeos: I'll cjeck
[09:00] <mzanetti> check
[09:14] <dednick> Saviq: looking to pick up a work item. only one left in month 5 unassigned and not in progress is 'transition to google-test/mock.'
[09:16] <tsdgeos> MacSlow: can you top approve it too?
[09:17] <Saviq> dednick, not all of the Components are yet tested (they're not split into separate work items
[09:17] <Saviq> dednick, and generally there's much more stuff that needs tests
[09:17] <MacSlow> tsdgeos, I did
[09:18] <dednick> Saviq: ok, sure. i'll take a look
[09:18] <tsdgeos> MacSlow: you only "comment approved", not "top approved" https://code.launchpad.net/~aacid/unity/removeUnusedFunction/+merge/154416 see Status is still "Needs Review"
[09:19] <MacSlow> tsdgeos, ah that... what about the failing/broken test?
[09:19] <tsdgeos> MacSlow: read the comment
[09:19] <MacSlow> tsdgeos, ah... seen the other branch
[09:19] <tsdgeos> MacSlow: i can rettrigger the test run if you prefer
[09:19] <MacSlow> tsdgeos, done
[09:20] <tsdgeos> cheers
[09:20] <Saviq> dednick, but, if you want to take on the gtest transition, that's just fine, too
[09:22] <Saviq> dednick, it's only about the tests in plugins/, too, as those are the only C++ tests we have
[09:47] <mzanetti> tsdgeos: Saviq: this should work now: https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868
[09:49] <Saviq> mzanetti, cheers
[09:54] <sil2100> didrocks, davidcalle: hi! In the new 100 scopes approach, the 'command lens' will still be there?
[09:54] <tsdgeos> mzanetti: i'll give it a try now
[09:55] <davidcalle> sil2100, I can see it right now in the Dash, working along 100scopes, so I guess it is.
[09:56] <sil2100> davidcalle: oh, do I need to install something to get it working with unity from ppa:ubuntu-unity/experimental-prevalidation ?
[09:56] <sil2100> Since when I press alt+F2 it opens the home dash ;p
[09:56] <davidcalle> sil2100, my setup is a bit messy, but I think it should work OOTB
[09:57] <sil2100> heh, now it suddenly works!
[09:57] <sil2100> davidcalle: thanks, it seems my system had some problems then - now it's all ok
[09:57] <davidcalle> Oh, cool :)
[10:00] <didrocks> sil2100: confirming the alt-f2 not opening the command
[10:00] <didrocks> sil2100: do you mind please filing a bug?
[10:00] <didrocks> sil2100: unity upstream
[10:00] <didrocks> tag 100scopes
[10:12] <sil2100> didrocks: to fix it, I had to open the dash normally and then press alt+f2
[10:13] <sil2100> Now it opens correctly, but many command lens files anyway fail because the prev and next lens/scope keybindings with the command lens now work differently, buggily
[10:13] <sil2100> So it's another regression I think ;) (will open a bug for that as well)
[10:13] <sil2100> */files/tests
[10:13] <didrocks> sil2100: open bugs!
[10:13] <didrocks> :)
[10:51] <didrocks> dednick: hey!
[10:51] <didrocks> dednick: so, you should have been aware that Francis did some work as well on the autopilot tests for unity-100scopes
[10:52] <tsdgeos> Saviq: greyback: mzanetti: what's your opinion on this https://code.launchpad.net/~aacid/unity/doNotUseShellInHud/+merge/154661 ?
[10:52] <didrocks> dednick: do you mind merging his work and yours?
[10:52] <didrocks> dednick: then, once we get tests results without that, we can merge and rebuild and get the actual results
[10:52] <didrocks> dednick: sounds good?
[10:53] <Saviq> tsdgeos, +1
[10:53] <Saviq> tsdgeos, ah wait
[10:53] <Saviq> tsdgeos, so we can get rid of the warning by just "&& shell.applicationManager"
[10:54] <tsdgeos> Saviq: there is no shell in the hud tests
[10:54] <tsdgeos> i tried that first
[10:54] <Saviq> tsdgeos, right
[10:54] <tsdgeos> but still complained
[10:54] <tsdgeos> let me try again
[10:54] <Saviq> tsdgeos, I'm just not a fan of passing everything down the tree like that
[10:55] <greyback> nor am I
[10:55] <Saviq> 'cause it's gonna grow a lot
[10:55] <greyback> but I see why you need to do it. Perhaps we can attach a mock shell to all tests?
[10:55] <Saviq> yeah, a mock shell I'd rather
[10:55] <dednick> didrocks: i had a testing branch. i believe we've now duplicated the work. lp:~unity-team/unity/libunity-7.0-breakage-tests
[10:55] <tsdgeos> ok, i can do that
[10:55] <didrocks> dednick: yeah, that's why I'm pinging you :)
[10:55] <dednick> did we should probably merge francis' work into there
[10:55] <dednick> :) ok
[10:56] <didrocks> dednick: do you mind looking at https://code.launchpad.net/~fginther/unity/dash-tests-100-scopes/+merge/154648
[10:56] <didrocks> and get everything in one?
[10:56] <dednick> didrocks: sure.
[10:56] <didrocks> dednick: thanks a lot :)
[10:58] <jibel> didrocks, should I pull cu2d r274 into production or you do?
[10:59] <didrocks> jibel: feel free to do it
[10:59] <jibel> done
[10:59] <didrocks> thanks jibel :)
[11:00] <didrocks> dednick: do you need help? We should get that in trunk before the next hour (so that we don't block too much the tests which are taking 1h30)
[11:00] <dednick> didrocks: mine and his?
[11:00] <didrocks> (and I know you will have the u1 dash in payment feature to review as well)
[11:00] <sil2100> dednick: libunity-7.0-breakage-tests has some test fixes?
[11:00] <didrocks> dednick: yep :)
[11:00] <didrocks> sil2100: backlog the discussion :)
[11:01] <didrocks> dednick: I can help you if needed
[11:01] <dednick> didrocks: working on it as fast as possible. i think francis changes wont cause much trouble.
[11:01] <didrocks> great, do not hesitate if you need anything :)
[11:01] <dednick> didrocks: i'm just rebasing tests branch at the moment.
[11:02] <sil2100> I'm just wondering if it wouldn't be better to rename LensBar (and all Lens* things) to Scope* instead of having both in the unity emulators
[11:02] <didrocks> sil2100: let's not add more churn now
[11:02] <didrocks> sil2100: we are already way too late
[11:02] <sil2100> Ok
[11:02] <didrocks> and still have a huge TODO list :)
[11:03] <tsdgeos> mzanetti: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/211/console ??¿?¿
[11:04] <mzanetti> tsdgeos: I tried the aptitude thing.. doesn't work either.. its reverted and tests should pass again
[11:04] <tsdgeos> ok, shall i retrigger ci?
[11:04] <mzanetti> yes please
[11:07] <tsdgeos> dne
[11:08] <tsdgeos> Saviq: greyback: mzanetti: https://code.launchpad.net/~aacid/unity/mockShellInHudTest/+merge/154664 better?
[11:09] <mzanetti> tsdgeos: imo you should fix the HUD to not directly access "shell"
[11:09] <Saviq> mzanetti, we discussed that before
[11:10] <Saviq> mzanetti, we need an object (just one) that will hold global things
[11:10] <mzanetti> sorry... the US government doesn't let me do anything else than focusing on their 555555555 pages long form
[11:10] <Saviq> mzanetti, that's fine ;)
[11:10] <mzanetti> which just bailed out at 80% and I have to do it from scratch
[11:10] <Saviq> mzanetti, otherwise we'll just grow a ton of "property variant something"
[11:11] <Saviq> mzanetti, which I'm not a fan of, although I do see the argument
[11:11] <mzanetti> Saviq: no... I don't think adding a property to set the shell is the way to go
[11:11] <Saviq> mzanetti, what else would you have in mind?
[11:12] <mzanetti> Saviq: I'd rather say components should have signals and properties to reflect their state and logic changing the Shell's behavior should be in Shell.qml
[11:12] <Saviq> mzanetti, it's not about changing shell's behavior
[11:12] <Saviq> mzanetti, it's not writing nothing
[11:12] <Saviq> mzanetti, in that particular example it's just reading the list of running applications from the ApplicationManager
[11:13] <tsdgeos> Saviq: not even that, is reading the kb status
[11:13] <mzanetti> if its just one I'd still vote for having a property aplicationList... anyways... feel free to ignore me... just saying how I would "fix" it
[11:13] <Saviq> mzanetti, tsdgeos, what we could have is have "import Ubuntu.ApplicationManager 0.1"
[11:13] <mzanetti> Saviq: +1
[11:13] <Saviq> expose a singleton
[11:14] <Saviq> that would probably be the cleanest ultimate solution
[11:15] <tsdgeos> Saviq: problem with that is that you may bee exposing too much info to "third parties" that import that plugin?
[11:15] <Saviq> tsdgeos, that's just a question of partitioning the API correctly
[11:15] <Saviq> which we don't right now
[11:16] <tsdgeos> so want me to work on that? or just accept my little mock for the moment and write in a blueprint the Ubuntu.ApplicationManager thing?
[11:16] <Saviq> tsdgeos, no, for now we'll just go with your solution
[11:16] <Saviq> tsdgeos, I'd go for a QtObject {} instead, though
[11:16] <tsdgeos> ok
[11:16] <Saviq> tsdgeos, no need for them to be visual Item {} s
[11:17] <tsdgeos> right
[11:18] <Saviq> oh, I'm flying back in the big Airbus again...
[11:31] <MacSlow> Saviq, you get a ride on the A380?! :)
[11:31] <Saviq> MacSlow, yeah, second time
[11:32] <MacSlow> Saviq, sweet!
[11:32] <Saviq> it's surprisingly non-different ;)
[11:32] <Saviq> except for the fact it's huge and it takes an hour to board
[11:32] <MacSlow> Saviq, but you have a lot of more room to "run around" during the flight, don't you?
[11:33] <Saviq> MacSlow, sure, there's enough space to run ;)
[11:33] <MacSlow> Saviq, and don't they have outside-view (forward-facing) cameras you can connect to on your tv-screen?
[11:33] <Saviq> MacSlow, yeah, there's a bunch of cameras that you can watch
[11:33] <Saviq> MacSlow, but in general the infotainment system is the same crap
[11:35] <MacSlow> Saviq, win32-based?
[11:35] <Saviq> MacSlow, looked like it
[11:36] <Saviq> MacSlow, but regardless what's it based on, the displays are crap, the touchscreens are crap, the quality is crap...
[11:36] <Saviq> and the UI is crap
[11:36] <nic-doffay> Anyone have any advice on implementing a search history for PageHeader.qml?
[11:37] <sil2100> cyphermox: piing
[11:37] <MacSlow> nic-doffay, any requirements on the implementation?
[11:39] <nic-doffay> MacSlow, it's just for testing atm.
[11:39] <nic-doffay> Obviously to be extended at a later stage.
[11:40] <MacSlow> nic-doffay, easiest is to do it in JavaScript first and later bring it over to C++, when the design is right... but that's just me thinking into the blue and being still very new to QML & Co
[11:41] <nic-doffay> Is there any reason to choose Javascript over QML?
[11:41] <MacSlow> nic-doffay, at least that approach allows you the fastest turn-around cycles for quick prototyping I guess
[11:41] <MacSlow> nic-doffay, not really... it's just what I've seen in examples
[11:41] <Saviq> tsdgeos, python3-dbusmock isn't there for quantal, shall we add it to desktop-deps?
[11:42] <tsdgeos> Saviq: do we use it?
[11:42] <Saviq> tsdgeos, it's a HUD dep
[11:42] <Saviq> tsdgeos, we might drop it, it's probably just for testing
[11:42] <tsdgeos> Saviq: but only for some tests, everything still works otherwise
[11:43] <Saviq> tsdgeos, yeah, let's drop from build_unity
[11:43] <tsdgeos> or should, let me make sure
[11:44] <nic-doffay> MacSlow, what examples exactly?
[11:44] <dednick> didrocks: done. fginther's AP test branch is just the changes i'd made already, so it's not needed.
[11:44] <didrocks> dednick: great, mind rejecting this merge then? https://code.launchpad.net/~fginther/unity/dash-tests-100-scopes/+merge/154648
[11:45] <didrocks> dednick: let me approve yours
[11:45] <tsdgeos> mzanetti: "file:///home/phablet/shell/Dash/DashVideos.qml:142: ReferenceError: root is not defined" is that related to what you did with the history?
[11:45] <didrocks> dednick: link handy? :)
[11:45] <dednick> didrocks: https://code.launchpad.net/~unity-team/unity/libunity-7.0-breakage-tests/+merge/153607
[11:46] <didrocks> dednick: should I wait for the CI job to run?
[11:46] <didrocks> with your last commit ;)
[11:47] <dednick> didrocks: probably :)
[11:47] <didrocks> let's see then, looking at the code itself :)
[11:47] <dednick> it's about 6k lines
[11:47] <didrocks> dednick: yeah, I've already given a look before TBH, just looking at your last commit
[11:48] <sil2100> didrocks: dednick: I checked the autopilot parts, and they look good
[11:48] <didrocks> sil2100: thanks!
[11:48] <sil2100> The gtest parts, well, I hope didrocks already browsed through those ;p
[11:49] <didrocks> yep ;)
[11:49] <sil2100> dednick: but yay, good thing that you removed the *lens versions and replaced them with the *scope ones, that was the only thing that bothered me in Francis's branch
[11:50] <dednick> sil2100: yeah. i essentially just did a find/replace :)
[11:51] <sil2100> dednick: I think that's better this way - having a LensBar and ScopeBar at once was really confusing ;)
[11:51] <dednick> sil2100: and i was getting loads of warnings about depricated mouse/keyboard functions being used. so i updated the keyboard/mouse work.
[11:51] <tsdgeos> Saviq: yes, works fine without it, you remove python3-dbusmock or want me to?
[11:52] <dednick> sil2100: not sure if that is going to cause issues with older AP version or not though. I was using raring.
[11:54] <sil2100> dednick: I think it's good to use the most recent changes here anyway, so it's good to have those modified
[11:55] <MacSlow> nic-doffay, uff.... I didn't keep the links around...
[11:57] <mzanetti> tsdgeos: history?
[11:57] <tsdgeos> mzanetti: the search history thing?
[11:58] <mzanetti> tsdgeos: hmm.. would need check
[11:58] <MacSlow> nic-doffay, the history is meant to only store strings? I think QMLs ListModel is probably worth a look
[11:59] <nic-doffay> MacSlow, pretty much.
[11:59] <nic-doffay> For the time being at least.
[11:59] <nic-doffay> I'll look into it. Thanks!
[12:00] <MacSlow> nic-doffay, don't know how easy it is to search through it... do you have to keep persistence of the history (across power-cycles)?
[12:00] <MacSlow> nic-doffay, or is the testing not that expanding?
[12:01] <nic-doffay> It's not that expanding at the moment. I think the best idea would perhaps be to leave it as is until more specs are received for the class.
[12:01] <nic-doffay> Obviously write the further tests as the component is extended.
[12:02] <Saviq> tsdgeos, can you do, please?
[12:06] <Saviq> tsdgeos, ignore, /me doing
[12:07] <tsdgeos> Saviq: ok, sorry
[12:07] <tsdgeos> Saviq: still can do if you prefer
[12:07] <Saviq> tsdgeos, that's fine, was otp but done now
[12:07] <Saviq> oh we passed r500 mark
[12:08] <Saviq> tsdgeos, it's yours, happy r500 ;) :D
[12:08] <tsdgeos> weeeeeeeeeeeeee
[12:17] <sil2100> cyphermox: ping #2
[12:17] <didrocks> sil2100: I think he will be there in a couple of hours
[12:18] <didrocks> dednick: CI failed
[12:18] <sil2100> didrocks: ah, ok, since I never know which timezone he is, since yesterday pinging did not work ;)
[12:18] <didrocks> sil2100: he's in Canada
[12:18] <didrocks> quebec more exactly :)
[12:20] <dednick> didrocks: checking
[12:20] <sil2100> Ah, thanks :)
[12:31] <nic-doffay> Might need design input for a PageHeader bug, it seems it needs more work.
[12:49] <Saviq> nic-doffay, what's up in there?
[12:50] <nic-doffay> The layout depends on the various states Saviq . At the moment there's a bug that if you set the text the search container anchors over it.
[12:50] <nic-doffay> Need direction on what to do with the class next and how to fix that.
[12:51] <Saviq> nic-doffay, not sure what you mean there, the layout depends mostly on whether there's enough space to have the header title and the search entry next to each other
[12:52] <Saviq> nic-doffay, if not, the search entry goes above the header title
[12:52] <Saviq> what's the issue there?
[12:59] <nic-doffay> I didn't know whether to put it above or below Saviq
[12:59] <Saviq> nic-doffay, it needs to be above the title, so that it slides down from the top
[13:00] <Saviq> nic-doffay, but it's like that already
[13:02] <nic-doffay> Not when I set it from my test.
[13:02] <nic-doffay> Saviq, ^
[13:03] <nic-doffay> The label that is.
[13:04] <Saviq> nic-doffay, it depends on the width of the item, maybe it's wide enough that it fits side-by-side?
[13:05] <cyphermox> sil2100: what'su p?
[13:05] <nic-doffay> It's wider Saviq
[13:05] <Saviq> nic-doffay, can you show your test please?
[13:06] <cyphermox> didrocks, you published autopilot-qt?
[13:07] <didrocks> cyphermox: yeah, you pushed the fix for powerpc a little bit too late (the daily started before) so the process was stuck, I just rerun it and published while I was at it :)
[13:07] <kgunn> tsdgeos: found one oddity in my trying to use ./run_on_device, my canonical ssh key isn't the default id_rsa.pub, it was id_rsa_canonical.pub
[13:07] <nic-doffay> Saviq, https://pastebin.canonical.com/87390/ http://tinypic.com/view.php?pic=nqveyr&s=6
[13:07] <cyphermox> didrocks: that's weird, I had rerun it after it landed too
[13:07] <cyphermox> I really thought it was good, there must have still been a little something wrong
[13:07] <cyphermox> OH
[13:07] <Saviq> nic-doffay, ah you mean they don't fit next to each other?
[13:07] <didrocks> cyphermox: probably, anyway, no worry :)
[13:08] <nic-doffay> Yes.
[13:08] <cyphermox> didrocks: the old source was probably not superseded yet or something
[13:08] <Saviq> nic-doffay, yeah, that wasn't taken into account properly there
[13:08] <Saviq> nic-doffay, "narrowMode: parent.width < units.gu(60)"
[13:10] <didrocks> cyphermox: yeah, probably
[13:10] <didrocks> cyphermox: anyway, thanks for the fix! now in distro :)
[13:10] <Saviq> nic-doffay, should instead check if parent.width > label.contentWidth + units.gu(40) or so
[13:10] <didrocks> cyphermox: you probably have the other stacks still to look at
[13:10] <nic-doffay> I'll experiment Saviq , thanks.
[13:11] <cyphermox> yup
[13:26] <cyphermox> didrocks: I think libindicator also ran too early, it didn't catch the revert of indicator-ng changes, I'd rerun it unless you think that's a bad idea
[13:27] <didrocks> cyphermox: sure, please do :)
[13:29] <cyphermox> also re: your hack for autopilot-qt in watch-ppa...
[13:29] <cyphermox> that's all that was missing really ;)
[13:29] <cyphermox> but I wonder if launchpad can't tell us which architectures are targetted by source upload XYZ instead
[13:32] <didrocks> cyphermox: I know the long term plan for it
[13:32] <didrocks> cyphermox: just I want to have time for putting under tests
[13:32] <didrocks> before refactoring
[13:32] <cyphermox> ok
[13:34] <cyphermox> hmm crap that won't work
[13:34] <cyphermox> didrocks: just rebuilding, I can see the branch for jenkins is updated but the version to upload didn't get bumped
[13:35] <cyphermox> e.g. it's still trying to make 12.10.2daily12.03.21, which is obviously already published, so it skips right back to the check phase
[13:35] <didrocks> hum
[13:35] <cyphermox> this can wait until tomorrow though
[13:35] <didrocks> cyphermox: how are you running it?
[13:35] <cyphermox> there's effectively no change
[13:35] <didrocks> ah
[13:35] <cyphermox> I did ./cu2d -R indicators libindicator
[13:35] <didrocks> ok
[13:35] <didrocks> and libindicator has no change?
[13:36] <cyphermox> it's a revert of a change we don't want in
[13:36] <didrocks> yep
[13:36] <didrocks> one sec
[13:36] <didrocks> looking at the branch
[13:36] <cyphermox> you'll see the latest commit in /var/lib/jenkins/cu2d/work/head/indicators/libindicator
[13:36] <didrocks> cyphermox: ah, but
[13:37] <didrocks> libindicator is not published
[13:37] <didrocks> to distro
[13:37] <cyphermox> what do you mean
[13:37] <cyphermox> no, it's in the PPA
[13:37] <didrocks> cyphermox: ok, well, nothing to worry in this case, isn't it?
[13:37] <cyphermox> well, I see it as a bug
[13:37] <didrocks> why?
[13:37] <didrocks> we shouldn't upload to distro a change + it's revert
[13:37] <didrocks> its*
[13:37] <didrocks> it's an explicit feature in the code
[13:38] <didrocks> to avoid uploading to distro an "empty change"
[13:38] <cyphermox> hmm
[13:38] <cyphermox> isn't the reverting commit explicitly a new change?
[13:38] <Saviq> kgunn, how did that affect you? it doesn't matter which ssh key is sent
[13:38] <didrocks> cyphermox: it's not from the distro point of view
[13:38] <cyphermox> no, i understand that
[13:38] <cyphermox> but how do you detect this?
[13:38] <didrocks> cyphermox: comparing to latest released version
[13:39] <cyphermox> you're comparing every commit to every other commit? ;D
[13:39] <cyphermox> ah
[13:39] <didrocks> released being "in distro"
[13:39] <cyphermox> I guess that makes sense then, yeah
[13:39] <Saviq> kgunn, unless you changed your default to use the canonical one?
[13:39] <didrocks> cyphermox: no, I forgot that idea :p
[13:39] <Saviq> kgunn, in which case ssh'ing onto the device would fail?
[13:39] <didrocks> cyphermox: in that case, if you don't want the ppa to have the change
[13:39] <didrocks> cyphermox: you can just remove the package from the ppa
[13:39] <cyphermox> didrocks: nah it's fine, I understand
[13:39] <didrocks> ok ;)
[13:39] <didrocks> but to be clear, until we have a new commit
[13:40] <cyphermox> this can all wait until tomorrow and should be fine
[13:40] <didrocks> nothing will be "good to publish"
[13:40] <cyphermox> yeah, I get it now
[13:40] <didrocks> even tomorrow
[13:40] <didrocks> if nothing more is in the branch :)
[13:40] <cyphermox> of course if you compare the code from the previously uploaded to distro with that you have now, there are no code changes
[13:40] <didrocks> cyphermox: yeah, we should really see the ppa as a "place for validation", but the real source of truth to know if we want to do something is the distro
[13:40] <cyphermox> didrocks: right, the ppa won't have the right thing, but indicators will be green and not try to upload something it shouldn't
[13:41] <didrocks> exactly
[13:41] <Saviq> kgunn, we should probably use ssh-copy-id and prompt for the password setup-time
[13:42] <kgunn> Saviq: yep...busy right now...i'll interact in a bit
[13:42] <Saviq> kgunn, sure
[13:48] <tsdgeos> kgunn: yes that key thing happens here too, not sure how to easily solve that other than adding a parameter to let you set which key you want to use
[14:23] <tsdgeos> meh, my raring doesn't like the hangout stuff much
[14:24] <tsdgeos> firefox died like 4 times :-/
[14:24] <Saviq> tsdgeos, yeah, go for chromium
[14:24] <Saviq> tsdgeos, for hangouts
[14:24] <Saviq> tsdgeos, the google talk plugin is b0rked
[14:25] <tsdgeos> chromium uses a different plugin?
[14:25] <tsdgeos> or is juts better at talking to itself?
[14:27] <Saviq> tsdgeos, I think it's just better
[14:28] <mzanetti> didrocks: I'd need your help for some package-fu
[14:28] <mzanetti> didrocks: have a minute?
[14:33] <mzanetti> kgunn: you joining the standup?
[14:33] <Saviq> greyback, mumble?
[14:33] <greyback> Saviq: ok
[14:47] <mzanetti> dednick: hey. I haven't managed to create a nice page yet, so I forwarded you the introduction mail I wrote for nic-doffay
[14:48] <tsdgeos> Saviq: did you get to crate a branch to remove the python-dbusmock thing?
[14:48] <Saviq> tsdgeos, yeah, there's two more things to remove, just verifying it works now
[14:49] <dednick> mzanetti: thanks for that.
[14:49] <tsdgeos> Saviq: oka
[14:50] <tsdgeos> mzanetti: quick reviews of https://code.launchpad.net/~aacid/unity/mockShellInHudTest/+merge/154664 and https://code.launchpad.net/~aacid/unity/testHudExecuteCommand/+merge/154654 ?
[14:50] <mzanetti> tsdgeos: ofc
[14:56] <didrocks> mzanetti: back from exercice, can help you after a hangout, in 30 minutes
[14:56] <mzanetti> didrocks: ofc
[14:56] <mzanetti> thanks
[14:57] <fginther> mterry, ping
[14:59] <fginther> mterry, https://jenkins.qa.ubuntu.com/job/cu2d-indicators-head-2.2check/114/console
[14:59] <fginther> mterry, the cu2d-autopilot-report script changed, but the job didn't change to match
[14:59] <mterry> didrocks, ^
[15:00] <didrocks> jibel: ^
[15:00] <didrocks> mterry: there was an issue in the delta counting
[15:00] <didrocks> fginther: ^
[15:00] <didrocks> (in unity tests)
[15:00] <didrocks> this has been fixed this morning
[15:00] <didrocks> and jibel changed the script for it
[15:01] <mzanetti> tsdgeos: whats the reason to make it a QtObject?
[15:01] <tsdgeos> mzanetti: Saviq commented it didn't need to be graphic, and it's true, that assumes a QtObject uses less memory than an Item
[15:01] <jibel> fginther, didrocks I'll update the jobs. I was waiting for the jobs to finish this morning then moved to something else.
[15:02] <mzanetti> ahh... right... makes sense
[15:02] <mzanetti> ok
[15:02] <didrocks> jibel: do you mind updating the experimental stack first?
[15:02] <didrocks> I want to rerun those :)
[15:02] <didrocks> jibel: give me the green flag once ok
[15:02] <fginther> jibel, thanks. just making sure it was noticed
[15:03] <mterry> didrocks, yeah I was hoping to get a clean run of unity today too.  You suggest doing experimental then head?
[15:04] <didrocks> mterry: yeah, experimental is really the high priority today
[15:04] <jibel> didrocks, done for experimental
[15:04] <didrocks> thanks jibel
[15:07] <mterry> didrocks, (why?)  I would have guessed head would be, to make one last release before UIF
[15:07] <didrocks> mterry: yeah, but you know, this small 100scopes project… ;)
[15:07] <didrocks> already late for FF and UIF :p
[15:08] <mterry> didrocks, ah fair
[15:08] <didrocks> fginther: speaking of which https://code.launchpad.net/~unity-team/unity/libunity-7.0-breakage-tests/+merge/153607 is running, isn't it?
[15:08] <didrocks> mterry: I wouldn't prioritize it otherwise TBH :)
[15:08] <didrocks> mterry: just the conditions are exceptional
[15:08] <mterry> didrocks, sure, sure
[15:08] <didrocks> fginther: your magic is broken, see, I tried again to paste it here but this time, it's not merged :p
[15:09] <fginther> didrocks, but it is running
[15:09] <fginther> didrocks, maybe you shoulld paste harder next time :-)
[15:10] <didrocks> https://code.launchpad.net/~unity-team/unity/libunity-7.0-breakage-tests/+merge/153607
[15:10] <didrocks> fginther: snif ^
[15:10] <fginther> ha!
[15:10] <didrocks> :p
[15:15] <jibel> didrocks, https://code.launchpad.net/~jibel/cupstream2distro-config/cu2d-autopilot-report_with_sysid/+merge/154728
[15:16] <didrocks> jibel: approved, the merger will take care of it, but that shouldn't stop you to deploy on the head stacks :)
[15:20] <fginther> didrocks, merged!
[15:20] <didrocks> fginther: yeah, let's get it built now and run!
[15:20] <didrocks> fginther: thanks :)
[15:24] <didrocks> mzanetti: yep, so what's up? :)
[15:25] <mterry> didrocks, OK, I'm going to start to pre-review the scopes stack for MIR I guess.  The list of packages is in the FFe?
[15:26] <didrocks> mterry: you read my mind!
[15:26] <didrocks> mterry: that was on my checklist for today :)
[15:26] <didrocks> mterry: yes please, the FFe as all the package
[15:27] <didrocks> mterry: there is a "new package" section
[15:27] <didrocks> mterry: for seb and I, we already have done the NEW review
[15:27] <didrocks> mterry: FYI, most of the scopes are exactly under the same model, there is no COPYING, but as there is just a few files, the license is obvious and so not needed
[15:27] <didrocks> you will notice as well that the Vcs-Bzr is pointing to an unexisting project (yet)
[15:28] <didrocks> as all scopes will be in separate lp projects in the end
[15:28] <mterry> k
[15:29] <didrocks> mterry: do we need to create another bug?
[15:29] <didrocks> mterry: or have the FFe being a MIR?
[15:30] <mzanetti> didrocks: hey. I have an issue in one of my jenkins jobs:
[15:30] <mterry> didrocks, I'd prefer a separate bug, so we don't overload the status of the ffe with the mir meanings
[15:30] <mterry> didrocks, but for now, I'll work off the FFe
[15:30] <mzanetti> didrocks: I get a .deb package from a builder job, which I need to install and execute autopilot tests on it
[15:31] <mzanetti> didrocks: right now I do this:
[15:31] <mzanetti> dpkg -i package.deb || true # will fail because of missing deps
[15:31] <didrocks> mterry: thanks
[15:31] <mzanetti> apt-get -f install # installs deps
[15:31] <mzanetti> dpkg -i package.deb # will succeed now as deps are here
[15:32] <didrocks> waow
[15:32] <didrocks> hackish :p
[15:32] <mzanetti> didrocks: yes... and it has 1 special case where it fails :/
[15:32] <mzanetti> didrocks: I'm searching for a better way now but couldn't find anything that does not involve parsing dpkg -I output myself
[15:32] <didrocks> mzanetti: just trying to decipher, you are running autopilot on an installed machine, with ui and everything, right?
[15:32] <mzanetti> didrocks: yes
[15:33] <didrocks> mzanetti: it's a group of packages you are testing, then?
[15:33] <didrocks> not only one?
[15:33] <mzanetti> didrocks: right now its only one
[15:33] <didrocks> but in the grand plan of future?
[15:33] <didrocks> it's like for us, you are testing a "stack"?
[15:33] <mzanetti> didrocks: this would apply to integration tests with multiple packages too I guess
[15:33] <didrocks> mzanetti: yeah, so I can still answer to your question
[15:34] <didrocks> mzanetti: but I think we should do that in the daily, with the same process than the rest
[15:34] <didrocks> meaning, having a jenkins job installing a machine
[15:34] <didrocks> installing from a ppa
[15:34] <didrocks> (the set of packages)
[15:34] <didrocks> and running the tests on them
[15:34] <didrocks> making sense?
[15:35] <mzanetti> didrocks: makes sense for a full integration test szenario. but in this case I have a base ubuntu system and just need to test this package on top of it
[15:35] <mzanetti> didrocks: before the package gets released to a ppa
[15:35] <mzanetti> before the branch gets merged actually
[15:36] <didrocks> mzanetti: oh, and you are not afraid of time to get one branch merged?
[15:36] <didrocks> mzanetti: you want integration/functional tests to be run everytime, it seems?
[15:37] <mzanetti> didrocks: yeah... we're doing that already... it works quite fine (except with one problem with the above commands)
[15:37] <didrocks> ok
[15:37] <didrocks> mzanetti: let's see if it can scale, but let's start with that
[15:37] <didrocks> so you need to create a local repo
[15:37] <didrocks> for that:
[15:37] <didrocks> echo "deb file:/path/to/your/debs ./" >> /etc/apt/sources.list
[15:37] <didrocks> cd /path/to/your/debs
[15:38] <didrocks> dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
[15:38] <didrocks> apt-get update
[15:38] <didrocks> mzanetti: that should do it ^
[15:38] <mzanetti> didrocks: nice! I'll give it a shot!
[15:38] <didrocks> then, just apt-get install your_binary :)
[15:38] <mzanetti> thanks a bunch
[15:38] <didrocks> yw!
[15:39] <mzanetti> didrocks: regarding scaling... we're running only the test suite of that particular app. so I think it should be fine for apps...
[15:39] <jibel> I redeployed the stacks indicators, oif, and unity with the fix to archive the results at the right place.
[15:39] <mzanetti> didrocks: I am a bit concerned for the shell indeed
[15:39] <mzanetti> that might blow it
[15:39] <didrocks> mzanetti: yeah, let's see, the current shell integration tests are taking 1h30
[15:39] <didrocks> mzanetti: so, will see, but at least, we need to rerun all those per stacks in the daily
[15:39] <mzanetti> didrocks: yeah... But I don't plan on having that many autopilot tests for the new shell
[15:39] <didrocks> mzanetti: with a fresh image and everything
[15:40] <didrocks> mzanetti: as long as it's functionnaly covered, yeah, less is better :)
[15:40] <didrocks> thanks jibel!
[15:40] <jibel> yw
[15:41] <mzanetti> didrocks: I plan on doing all functionality tests in qttest/googletest and really only test integrational stuff with autopilot
[15:41] <didrocks> mzanetti: that sounds to me the best plan, having this clear and real separation :)
[15:41] <mzanetti> at least I'll try to get the team there
[15:41] <didrocks> hehe, let's see!
[15:41] <mzanetti> but looks promising :)
[15:42] <didrocks> great
[15:42] <didrocks> mzanetti: I think once this 100scopes/indashpayement things are done, we can sync up on unity next gen, mir, and daily releases
[15:42] <didrocks> also touch apps :)
[15:42] <mzanetti> didrocks: ack
[15:50] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-test-dashpreview/+merge/154741
[15:52] <tsdgeos> mzanetti: doing a small refactor here, will get to it in 15 min or so
[15:53] <mzanetti> nic-doffay: hey. allright with the page header stuff?
[15:53] <mzanetti> or you stuck somewhere?
[15:53] <mzanetti> tsdgeos: not in a hurry
[15:54] <nic-doffay> mzanetti, yeah for now. I've been drafted to fix some Nux problem though for the release.
[15:54] <mzanetti> nic-doffay: ah ok
[16:43] <mzanetti> tsdgeos: regarding: https://code.launchpad.net/~aacid/unity/testHudExecuteCommand/+merge/154654
[16:43] <tsdgeos> yep?
[16:43] <mzanetti> tsdgeos: shouldn't this use the resetToInitialState() method introduced in the other MP instead of hud.state = "initial" ?
[16:43] <tsdgeos> doesn't?
[16:44]  * tsdgeos mixed 3 branches so maybe forgot :D
[16:44] <mzanetti> yeah.. it doesn't...
[16:44] <tsdgeos> ah, the other branch is on top of this
[16:44] <tsdgeos> i.e. i did this first and then the other and the other fixes this too
[16:45] <tsdgeos> see https://code.launchpad.net/~aacid/unity/testHudRefactor/+merge/154743
[16:45] <tsdgeos> last chunk is regarding this one
[16:46] <tsdgeos> and they are "properly" stacked in launchpad
[16:48] <mzanetti> right... I see it now
[16:48] <mzanetti> ok. fine then
[16:52] <tsdgeos> mzanetti: i don't understand test_columns
[16:53] <mzanetti> tsdgeos: on the phone, the preview is 1 column, on the tablet its 2 columns
[16:53] <mzanetti> tsdgeos: however, both columns are there all the time, but the content gets moved around to column 1 or 2
[16:54] <mzanetti> tsdgeos: this test just searches the column's subtree if the content is there
[16:54] <tsdgeos> i see
[16:54] <tsdgeos> mzanetti: what about test_ensure_buttons_visible
[16:55] <tsdgeos> is it really useful?
[16:55] <tsdgeos> i mean you're testing only "local" objects in there?
[16:55] <mzanetti> tsdgeos: yes... but the mouseClick() would fail in case the DashPreview would not put the buttons where they belong
[16:56] <mzanetti> tsdgeos: could be better tho... I agree
[16:56] <mzanetti> any idea?
[16:56] <mzanetti> tsdgeos: what I wanted to test is this:
[16:56] <tsdgeos> so you're basically testing that assigning something to buttons puts it on screen
[16:56] <mzanetti> I set a component to buttons: and I want to make sure that the DashPreview actually puts those buttons somewhere in the ui
[16:56] <tsdgeos> right?
[16:56] <mzanetti> yes
[16:56] <tsdgeos> ok
[16:57] <tsdgeos> do you think it's worth putting this and the previous explanations etiher as comments in the code or in the commit message?
[16:57] <mzanetti> tsdgeos: can do if you think its not clear enough
[16:58] <tsdgeos> i'd appreciate it yeah
[16:58] <mzanetti> ok
[16:58] <tsdgeos> tx
[17:02] <tsdgeos> besides that looks good to go
[17:03] <mzanetti> tsdgeos: done
[17:11] <mzanetti> Saviq: should we merge this? https://code.launchpad.net/~unity-team/unity/phablet.dashBar_bottomswipe/+merge/150847
[17:11] <mzanetti> Saviq: I think its ok... I don't like that the tests take so long, but there is a reason for it... so I would give my ok
[17:12] <Saviq> mzanetti, my reservation is that it's a copy from Launcher.qml
[17:12] <Saviq> more or less
[17:12] <Saviq> mzanetti, it should be abstracted instead
[17:12] <mzanetti> Saviq: thats true, yes
[17:13] <tsdgeos> lol, i was scared something broke in https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner/228/?#showFailuresLink
[17:13] <tsdgeos> but then realized it's probably that MacSlow's hell is not starting because a missing definition or something
[17:15] <Saviq> MacSlow's hell? ;)
[17:16] <tsdgeos> shell :D
[17:17] <Saviq> tsdgeos, I can't get the freakin thing to build in a quantal vm
[17:18] <Saviq> nux build fails with an internal compiler error...
[17:18] <tsdgeos> lol
[17:18] <tsdgeos> that must be new
[17:18] <tsdgeos> it was working fine a few days ago
[17:18] <tsdgeos> want me to give it a try
[17:18] <tsdgeos> ?
[17:18] <Saviq> tsdgeos, it was working today (once)
[17:19] <tsdgeos> maybe they changed the nux code?
[17:19] <Saviq> tsdgeos, we're pulling lp:nux/phablet
[17:19] <tsdgeos> oh
[17:19] <Saviq> one last try for today, then...
[17:19] <tsdgeos> then your vm is borked?
[17:19] <kgunnAFK> tsdgeos: Saviq ...ok i admit i screwed around with changing my id_rsa_canonical.pub to id_rsa.pub
[17:19] <kgunnAFK> & i blew away my known_hosts
[17:20] <Saviq> kgunnAFK, yikes
[17:20] <kgunnAFK> which seemed to help in one go
[17:20] <kgunnAFK> but now its getting stuck on the phablet@ password prompt
[17:20] <Saviq> kgunnAFK, pastebin please
[17:23] <kgunnAFK> https://pastebin.canonical.com/87440/
[17:23] <kgunnAFK> i did actually succeed at one point....
[17:24] <kgunnAFK> but not repeatable for me
[17:24] <Saviq> kgunnAFK, "Agent admitted failure to sign using the key."
[17:26] <Saviq> kgunnAFK, call `ssh-add`
[17:26] <Saviq> kgunnAFK, your ssh agent still tries to use your previous default identity
[17:26] <kgunnAFK> the one on the device?
[17:27] <Saviq> kgunnAFK, no
[17:27] <Saviq> kgunnAFK, on your laptop
[17:27] <Saviq> desktop
[17:27] <Saviq> workstation
[17:27] <kgunnAFK> got it
[17:28] <kgunnAFK> i did change my ssh config to use the correct identity...but.... :-/
[17:28] <Saviq> kgunnAFK, yeah, logout / login would help, too
[17:28] <kgunnAFK> obviously not enough
[17:28] <kgunnAFK> ah good one
[17:28] <Saviq> kgunnAFK, but anyway, it would've been enough for you to ssh-copy-id to the device
[17:29] <Saviq> it would then use the canonical key
[17:29] <Saviq> I'll try and make it a more robust
[17:30] <kgunnAFK> yeah...when i just mod'd the run_on_device to call explicitly my id_rsa_canonical...it worked
[17:30] <kgunnAFK> sort of
[17:30] <kgunnAFK> then i figured (stupid) that i should go ahead and change that to avoid future snafus
[17:30] <kgunnAFK> (great idea)
[17:30] <Saviq> kgunnAFK, good like any other, really
[17:31] <Saviq> kgunnAFK, and it'd have worked, if only you relogged :)
[17:31] <kgunnAFK> :0
[17:32]  * tsdgeos logs off for the day, tomorrow more!
[17:38] <Saviq> kgunnAFK, but anyway, I will make it so that it requires a password by default, and only copies the ssh key when asked explicitly
[18:45] <sil2100> didrocks: soooo
[18:45] <sil2100> didrocks: I looked briefly through the 100-scopes test results just now
[18:45]  * didrocks listens :-)
[18:45] <sil2100> didrocks: a short overview:
[18:46] <sil2100> The test_command_lens* tests fail because of the 'alt+f2' bug we encountered, so that's -6 tests for each platform
[18:47] <didrocks> regression catching!
[18:47] <sil2100> The test_dash.DashKeyNavTests are also regressions, but regressions in unity introspection - the lens/scope code changed and the number of rows returned by unity is invalid now, so the tests fail
[18:47] <sil2100> I'll e-mail dednick later on regarding this and we'll think of who could take care of this one
[18:48] <didrocks> sweet :)
[18:48] <sil2100> This would be -5 failures for each platform again
[18:48]  * didrocks counts, still 5 to go :)
[18:48] <sil2100> The shopping lens tests fail, but well, those were never really well written ;p Not sure what to do, I think maybe a rewrite is needed!
[18:49] <didrocks> sil2100: but they were passing on trunk?
[18:49] <sil2100> didrocks: yes, they are, but well, trunk looks a different when shopping results are taken into account
[18:49] <sil2100> didrocks: I think we can fix that somehow anyway
[18:49] <sil2100> Just need to think about it a bit
[18:50] <didrocks> sure :)
[18:50] <dednick> sounds promising
[18:50] <bschaefer> correct, the shopping lens tests looks for the application lens IIRC
[18:50] <bschaefer> sil2100, you can blame me haha
[18:50] <sil2100> bschaefer: nooo!
[18:50] <sil2100> Anyway, the rest I'll see later, but this is what I noticed
[18:54] <didrocks> sil2100: excellent work! :)
[18:55] <didrocks> thanks for deciphering that
[18:56] <didrocks> sil2100: maybe you can get the unity team to look at the introspection part?
[18:56] <didrocks> for the rest, fginther will maybe be of help?
[18:56] <sil2100> Will do some poking ;)
[18:56] <didrocks> (and ack for alt+F2, let's wait for the real fix)
[18:56] <didrocks> thanks dude!
[18:57] <sil2100> np! :)
[18:58] <sil2100> (here's the bug if anything https://bugs.launchpad.net/unity/+bug/1158231 )
[19:37] <tigrang> Anyone else notice that when clicking on the dash icon, the dash opens faster than when pressing the Super key?
[19:44] <hyperair> nope
[19:49] <bschaefer> tigrang, well the dash opens on super when the Super key is RELEASED no pressed and they both go through the same UBUS call soo I wouldn't expect it to be any slower....
[19:51] <bschaefer> (On super press the dash is opened in LauncherController.cpp:SendHomeActivationRequest, and click is in BFBLauncherIcon.cpp:ActivateLauncherIcon)
[20:05] <kgunn> Saviq: finally got back to it...ssh seems all happy-happy-happy
[20:06] <kgunn> but wondering if its because i'm trying to do this on a nexus7/grouper
[20:06] <kgunn> at least one line in run_on_device seems wrong
[20:06] <kgunn> where  is checks the device for SERVICEFILE
[20:06] <kgunn> does "tablet-services" only for "manta"....no grouper
[20:25] <kgunn> Saviq: changed manta to grouper for my case....seems to totally work
[20:26] <tigrang> bschaefer, heh yea I noticed after I wrote that
[20:26] <bschaefer> tigrang, :), otherwise we couldn't tell if the user wanted to open the Shortcut window (Holding Super key down)
[20:26] <tigrang> yea
[20:27] <bschaefer> to open the dash the key press, and release has to be within a tap time
[20:29] <Saviq> kgunn, right, we need a better determination of whether we're tablet or phone
[20:29] <tigrang> Is this strictly a dev channel or are questions about usage okay?
[20:29] <Saviq> tigrang, they're fine
[20:30] <tigrang> Is there a way to make the dash appear without fading in?
[20:31] <Saviq> dunno
[20:31] <bschaefer> tigrang, theres no setting, but its done in the DashController.cpp
[20:31] <bschaefer>   , timeline_animator_(90) set that to 0 and it'll be instant
[20:32] <tigrang> thanks
[20:32] <bschaefer> np!
[20:49] <kgunn> dandrader: ping
[20:49] <dandrader> kgunn, pong
[21:57] <tigrang> bschaefer, hey, so after disabling the fade in, it's more clear that there is a lag when using key shortcut than clicking the dash icon. I changed the shortcut from Super to Alt+F1 in ccsm and now it opens in the same time as clicking the dash icon. It only has an extra lag when using the Super key - any idea why?
[21:59] <bschaefer> tigrang, hmm well with a key press, it has to go through compiz and compiz has to send a message to unity saying a key has been pressed... i can't imagine it being a very noticeable amount
[22:00] <bschaefer> the click goes through nux, and it finds whats under the mouse, which is the launcher, then the launcher figures out which icon the mouse is under and sends an event to it then sends the UBUS message to open the dash
[22:02] <tigrang> it's noticeable, using key shortcut and typing misses the first few characters in the search box. I don't see why it's slower only when using the Super key as the shortcut - is the super key handled in a special way or somethign?
[22:02] <bschaefer> the super key does a bunch of things...
[22:03] <bschaefer> tigrang, soo my guess is all the bookeeping could be slowing it down
[22:04] <bschaefer> tigrang, but umm changing the shortcut shouldn't make a difference...
[22:05] <bschaefer> cause it should do the same things as super...but I really cant see a different with my machine.
[22:05] <bschaefer> tigrang, you'll need some hard numbers to figure out if its a lot slower or not...
[22:06] <bschaefer> (timing it)