[07:37] <didrocks> mzanetti: Saviq: hey, did you submit any talk for FOSDEM? I don't see them now that the proposal period is over
[07:46] <Saviq> didrocks, yeah, I did, and bregma, too
[07:52] <didrocks> Saviq: what's the title of your conference?
[07:52] <didrocks> I see bregma's one
[07:53] <Saviq> didrocks, "Ubuntu on phones and beyond"
[07:53] <didrocks> Saviq: ah, typo in your name :)
[07:53] <didrocks> Saviq: ok, all good, it's listed ;)
[07:53]  * Saviq was worried did not fill the forms right, they're rather convoluted
[07:55] <didrocks> Saviq: I won't even mention the backend-voting-side :p
[07:55] <didrocks> (we are back to using some google spreadsheet for easyness, due to that)
[07:58] <Saviq> ;)
[07:58] <Saviq> spreadshits FTW!
[08:08] <didrocks> heh
[08:34] <Saviq> tsdgeos, hey, could you work today on making the apps scope non-unfavouritable?
[08:35] <tsdgeos> yep
[08:35] <tsdgeos> i was talking with xavigarcia about some card stuff
[08:35] <tsdgeos> i will do that now
[08:36] <tsdgeos> and then maybe fix the race in qtmir we indentified with gerry yesterday
[08:36] <tsdgeos> that = non-unfavoritable
[08:37] <tsdgeos> bign landing btw \o/
[08:37] <tsdgeos> -n
[08:37] <tsdgeos> now if Cimi would review the moreAsyncDash ;)
[08:38] <tsdgeos> Saviq: do you know if ci is back ?
[08:39] <Saviq> tsdgeos, yeah, it should mostly be back
[08:39] <Saviq> tsdgeos, if you're touching cards, maybe you can have a look at bug #1393008
[08:39] <tsdgeos> yeah
[08:39] <tsdgeos> that was what we were talking about
[08:39] <Saviq> oh good
[08:39] <tsdgeos> that's not a bug according to spec
[08:39] <tsdgeos> :
[08:39] <tsdgeos> :D
[08:40] <Saviq> orly?
[08:40] <tsdgeos> yeah
[08:40] <tsdgeos> well if you read the spec in a certain way
[08:40] <tsdgeos> of course
[08:40] <Saviq> ah ok ;)
[08:40] <Saviq> thostr_, says it was working before ;)
[08:40] <tsdgeos> never
[08:40] <tsdgeos> the code says
[08:40] <tsdgeos> hasBackground = !isHorizontal && stuff;
[08:41] <tsdgeos> don't think that changed lately
[08:41] <Saviq> heh
[08:41] <tsdgeos> Saviq: can you log into http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/5023/rebuild ?
[08:41] <tsdgeos> well log
[08:41] <tsdgeos> does it even show up?
[08:43] <Saviq> tsdgeos, do you have the new VPN set up?
[08:43] <tsdgeos> probably not
[08:43] <Saviq> tsdgeos, kicked that rebuild
[08:44] <Saviq> tsdgeos, ok and as far as the spec goes, where did we read it that horizontal cards can't have backgrounds?
[08:44] <tsdgeos> i'm writing it down
[08:45] <Saviq> thanks
[08:45] <tsdgeos> done
[08:48] <tsdgeos> Saviq: imho our bug should be back to incomplete and add ubuntuux there for them to decide if what i understand is what they wanted to write
[08:48] <Saviq> tsdgeos, sure
[08:48] <tsdgeos> and bring back the designer that wrote that ^_^
[08:49] <Saviq> tsdgeos, yeah, you're right
[08:49] <Saviq> tsdgeos, it clearly says it can't be shaped, so no background
[08:51] <tsdgeos> well that's how we coded it yes
[08:59] <Saviq> pstolowski, I'll start prepping the unity8 counterpart for dash bottom edge
[09:00] <Saviq> pstolowski, but we'll have to wait for apps-special-after-all
[09:04] <pstolowski> Saviq, yeah, i'm going to prepare MP for that
[09:05] <Saviq> pstolowski, you want to ensure that plugin side?
[09:06] <tsdgeos> in case our 1 line of code fails :)
[09:07] <Saviq> tsdgeos, truth is we might need to have multiple special scopes for OEMs, or at least replacing the apps one
[09:07] <Saviq> tsdgeos, but then we don't need to implement that right now
[09:08] <tsdgeos> i'll go back
[09:08] <tsdgeos> to what we had
[09:08] <tsdgeos> i.e. lame
[09:08] <tsdgeos> showStar: model.scopeId != "clickscope" && (root.isFavoritesFeed || root.isOtherFeed)
[09:08] <tsdgeos> damn, that also makes it unmovable
[09:09] <tsdgeos> and we want it movable, right?
[09:10] <tsdgeos> hmmm
[09:11] <tsdgeos> and we need to make it unfavoritable also from das
[09:11] <tsdgeos> h
[09:11] <pstolowski> Saviq, yes, I had it before in the plugin as a safeguard, i just need to find and revert that commit
[09:11] <tsdgeos> is that something we do
[09:11] <tsdgeos> or that the plugin does
[09:11]  * tsdgeos checks
[09:11] <pstolowski> Saviq, but you also need to special case it in the shell (not to show star)
[09:12] <tsdgeos> something we do
[09:12] <Saviq> pstolowski, yup
[09:12] <tsdgeos> it's again something the scope should tell us
[09:12] <tsdgeos> if we're going to make this generic for the FUTURE
[09:12] <Saviq> trueth
[09:13] <Saviq> or at least the registry
[09:14] <tsdgeos> btw i just found a bug
[09:14] <tsdgeos> not sure if it's ui or backend
[09:14] <tsdgeos> but if you open manage dash, go to edit mode, reorder, leave edit mode and now click some scope, it will bring you to the "before reordering" position
[09:15] <tsdgeos> pstolowski: if i had to say something i'd say that's on your plate ↑
[09:16] <tsdgeos> but maybe not :D
[09:16] <Saviq> tsdgeos, worked fine here
[09:16] <Saviq> tsdgeos, is "some scope" favourited or not?
[09:16] <pstolowski> otp
[09:16] <tsdgeos> Saviq: yes, otherwise that's the point of the reordering breaking it
[09:17] <tsdgeos> and now it works
[09:17] <Saviq> oh there's one more thing
[09:17] <tsdgeos> :S
[09:17] <Saviq> the scope gets refreshed every time I click in Manage Dash
[09:17] <Saviq> sounds wasteful
[09:17] <tsdgeos> ah made it fail again
[09:17] <tsdgeos> it may be on our side
[09:18] <tsdgeos> will debug more
[09:19] <tsdgeos> meanwhile https://code.launchpad.net/~aacid/unity8/apps-special-after-all/+merge/244548
[09:20] <tsdgeos> Saviq: ok my way to reproduce, have 3 fav scopes, move 2 to 1, click on 3rd
[09:20] <tsdgeos> end in first
[09:21] <Saviq> tsdgeos, confirmed
[09:21] <tsdgeos> and it's probably our
[09:21] <tsdgeos> s
[09:21] <tsdgeos> looking at it now
[09:22] <Saviq> tsdgeos, could we have a test for apps-special-after-all?
[09:22] <tsdgeos> you want to test that !== works? :D
[09:24] <Saviq> tsdgeos, no, I want to test that there is no star next to the click scope
[09:24] <Saviq> or in the click scope's header
[09:24] <tsdgeos> Saviq: which is basically testing !==, it will still break when backend decides to rename the click scope to "mooscope" and we're still checking for !== "clickscope"
[09:25] <Saviq> tsdgeos, great, we'll have a failure that we might even be able to catch in proposed thanks to that test being executed on autopkgtest
[09:25] <Saviq> soon
[09:26] <tsdgeos> Saviq: no, we won't have a failure, why would we?
[09:26] <Saviq> tsdgeos, because if they changed, the star would be there when it shouldn't be?
[09:26] <tsdgeos> it's not like we use real scopes in tests
[09:26] <Saviq> tsdgeos, oh well, right
[09:26] <tsdgeos> so as i said, we're testing that !== works
[09:26] <Saviq> meh
[09:26] <tsdgeos> but if it makes you happy
[09:26] <tsdgeos> it's 10 minutes of my time
[09:26] <tsdgeos> so doing
[09:27] <Saviq> tsdgeos, I think we should have that test indeed
[09:27] <Saviq> tsdgeos, and while right now it might not make all kinds of sense
[09:28] <Saviq> it hopefully will once we have a property on scopes that decide whether they can be unfav'ed or not
[09:28] <tsdgeos> and nobody will remember to update the tests :D
[09:30] <pstolowski> Saviq, tsdgeos i guess I can add new role for such property in OverviewResultsModel
[09:31] <Saviq> pstolowski, not enough
[09:31] <Saviq> pstolowski, we need to know it for the scope as well, to show the star in the header or not
[09:31] <pstolowski> Saviq, tsdgeos and I'd special case apps in shell plugin for now (no configurability), but at least it won't bubble up
[09:31] <pstolowski> ah right
[09:33] <pstolowski> Saviq, so, new property in Scope interface? again special cased for now in shell plugin
[09:33] <pstolowski> ?
[09:33] <tsdgeos> i'd leave it as it is now tbh
[09:33] <Saviq> pstolowski, ↑
[09:33] <Saviq> pstolowski, once we know we do need to replace / add special scopes
[09:34] <Saviq> is when we'll deal with that
[09:35] <pstolowski> Saviq, tsdgeos ack
[09:47] <facundobatista> Hola!
[09:52] <tsdgeos> Saviq: tests added
[09:52] <Saviq> tsdgeos, thanks
[09:57] <Saviq> tsdgeos, did you push?
[09:57] <tsdgeos> nope :D
[09:57] <tsdgeos> and even then, there's a bug
[09:57] <Saviq> k
[09:59] <tsdgeos> now :)
[09:59] <tsdgeos> Saviq: ↑
[10:01] <Saviq> tx
[10:10] <tsdgeos> i hate listview
[10:31] <Saviq> tsdgeos, that's re: went to the wrong scope?
[10:31] <tsdgeos> ywah, i know what's wrong
[10:31] <tsdgeos> my workaround for a listview "bug" breaks it
[10:31] <tsdgeos> i'll add a few tests
[10:32] <tsdgeos> which we have none
[10:32] <tsdgeos> to at least make sure those two things work
[10:32] <tsdgeos> in a separate MR
[10:55]  * Saviq starts being afraid of cherry-picking...
[11:27] <Saviq> UUGH
[11:27] <tsdgeos> yeah
[11:27] <tsdgeos> Saviq: i appreciate you doing the cherry-picking, but it's most probably something the guy that did the original branch should do
[11:28] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563 has the fix for the issue i found with dragging + click with a test for it and some other stuff
[11:28] <Saviq> tsdgeos, it's not even that
[11:28] <Saviq> tsdgeos, the real problem is the ordering
[11:28] <tsdgeos> ah
[11:28] <Saviq> tsdgeos, like now we're landing the bottom edge
[11:28] <Saviq> tsdgeos, but there were things that changed for the performance fixes
[11:28] <tsdgeos> right
[11:29] <Saviq> tsdgeos, so it's conflicting (a bit) now, and will conflict again later, not to mention that I might actually break things
[11:29] <Saviq> tsdgeos, and then... there's unity-api, which has a launcher change that we don't (yet) want in rtm
[11:29] <Saviq> tsdgeos, so I need to cherry-pick that and do something weird with unity-api's version so that we don't break that...
[11:30] <Saviq> so that we can actually reconcile in the futuer
[11:30] <Saviq> but maybe it's gotta be what it's gotta be...
[11:32] <Saviq> and then there's you not being able to make your mind on how the test should work and changing it back'n'forth ;P
[11:32] <Saviq> but well, the test passed, so it must be right, right?
[11:36] <tsdgeos> totally
[11:36] <tsdgeos> :D
[11:36] <tsdgeos> Saviq: which test?
[11:37] <Saviq> tsdgeos, test_manage_dash_search_temp_scope
[11:37] <tsdgeos> ah don't worry about that one, we don't support search yet anyway
[11:37] <tsdgeos> so the skip() at the beginning is the important part
[11:37] <Saviq> tsdgeos, that's searching in *temp* scope
[11:37] <Saviq> tsdgeos, not in manage dash?
[11:38] <tsdgeos> no
[11:38] <tsdgeos> is searching in manage dash
[11:38] <Saviq> ok
[11:38] <tsdgeos> that's why it's called manage_dash_search
[11:38] <Saviq> tsdgeos, anyway, there was no tryCompareFunction(), then you added it when doing "less delegates" and then removed it again in bottom swipe :P
[11:38] <tsdgeos> he he
[11:38] <Saviq> tsdgeos, it's fine, I'm just trying to keep the diff sane
[11:40] <Saviq> mzanetti, can you please whip up a quick vivid silo with tsdgeos's fixes for the bottom edge?
[11:40] <mzanetti> kk
[11:40]  * Saviq tries not to land in rtm before vivid
[11:40] <Saviq> mzanetti, https://code.launchpad.net/~aacid/unity8/apps-special-after-all/+merge/244548 and https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
[11:40] <Saviq> mzanetti, if you could review the latter one, too, would be obliged
[11:41] <Saviq> ah and https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293 too
[11:41] <Saviq> tsdgeos, that's it, right ↑ ?
[11:43] <Saviq> greyback__, just discovered hash -d in znc, better'n'wd ;)
[11:45] <tsdgeos> mzanetti: Saviq: yeah that one too, though effectively it does nothing at the moment it's "better code"
[11:45] <greyback__> Saviq: Sorry, I've no idea what that sentence means. znc the IRC bouncer?
[11:45] <Saviq> greyback__, zsh, of course ;)
[11:46] <Saviq> greyback__, hash -d alias=/some/dir/foo
[11:46] <Saviq> greyback__, cd ~alias
[11:46] <greyback__> Saviq: there's a "jump" plugin I like a lot.
[11:47] <greyback__> ets you bookmark directories with a name, and then jump from one to another. Is very similar
[11:48] <Saviq> greyback__, sounds the same :), but IIRC jump lets you do more
[11:48] <greyback__> and have it aliased to "j" so I can just "j qtmir" to land in my qtmir root
[11:51] <Saviq> yup
[11:51] <Saviq> tsdgeos, https://code.launchpad.net/~unity-team/unity-api/rtm-14.09-staging/+merge/244567 please
[11:54] <Saviq> pstolowski, is there a citrain row for bottom dash rtm yet?
[11:54] <tsdgeos> Saviq: looks good, want me to approve?
[11:55] <Saviq> tsdgeos, yup
[11:55] <pstolowski> Saviq, no, but i have another silo where i'm currently building two other fixes (including department jumping fix)
[11:55] <Saviq> pstolowski, that's for vivid though?
[11:55] <pstolowski> Saviq, and it has shell plugin
[11:55] <pstolowski> Saviq, yes vivid
[11:55] <Saviq> pstolowski, I'm talking rtm
[11:56] <Saviq> this silo should only include bottom edge things IMO
[11:56] <pstolowski> Saviq, agree. but we need todays fix in vivid first
[11:57] <Saviq> pstolowski, do you have rtm branches yet?
[11:58] <Saviq> pstolowski, btw, you know we're limited to "3 fixes" per rtm silo? could we not land bottom edge separately?
[11:59] <pstolowski> Saviq, i only have rtm MP for plugin and it will need updating with todays fix
[12:00] <mzanetti> tsdgeos: I don't really understand what the issue is this one fixes: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
[12:00] <Saviq> pstolowski, sure, I don't have complete MPs yet, either
[12:01] <Saviq> pstolowski, but want to start early
[12:01] <pstolowski> Saviq, yeah, I know of limits. actually, is it 3 MPs or 3 bugfixes?
[12:01] <mzanetti> :)
[12:01] <Saviq> pstolowski, neither, it's 3 "fixes"
[12:01] <Saviq> pstolowski, it can be more or less MPs
[12:01] <pstolowski> Saviq, yeah... i already prepared target rtm-14.09 branch for unity-api (which wasn't branched yet)
[12:02] <tsdgeos> mzanetti: without the patch do this, get to manage dash, move second scope to first, click third scope, see how you're not in the third scope as you should be
[12:02] <Saviq> pstolowski, yeah, got an MP for that up already
[12:02] <pstolowski> cool
[12:02] <mzanetti> tsdgeos: thanks
[12:04] <Saviq> pstolowski, https://code.launchpad.net/~stolowski/unity-scopes-shell/manage-dash-rtm/+merge/244117 is the one?
[12:04] <tsdgeos> mzanetti: note there may be a race in the test, i got it failing 1 every 20 or so if i loop it
[12:04] <mzanetti> tsdgeos: you fixing that?
[12:04] <tsdgeos> having a look yes
[12:04] <pstolowski> Saviq, also, I've rtm silo 3 (rows #23) that needs qa sign off, or will block other landings of shell plugin
[12:04] <pstolowski> Saviq, yes, that's it
[12:05] <pstolowski> Saviq, it may also need dependency update
[12:05] <Saviq> pstolowski, you'll need to chase product folk to accept https://launchpad.net/bugs/1394155
[12:06] <Saviq> pstolowski, we'll need -api for the new silo too, right?
[12:08] <pstolowski> Saviq, unity-scopes-api? yes
[12:09] <mzanetti> tsdgeos: this one fails here all the time: test_manage_dash_move_current_click_other
[12:09] <tsdgeos> mzanetti: hmmm
[12:09] <tsdgeos> with the patch?
[12:10] <mzanetti> this branch: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
[12:10] <tsdgeos> you didn't revert the change in qml/Dash/Dash.qml
[12:10] <tsdgeos> right?
[12:10] <tsdgeos> can you add console.log("setCurrentScope", scopeId, scopeIndex); to Dash.qml::setCurrentScope after the for loop?
[12:11] <mzanetti> no, didn't revert that
[12:11] <mzanetti> trying the debug print
[12:13] <mzanetti> tsdgeos: qml: setCurrentScope MockScope1 1
[12:13] <tsdgeos> right
[12:13] <tsdgeos> that's wrong
[12:13] <tsdgeos> should be MockScope5 2
[12:14] <tsdgeos> you're probably hitting my race more often :D
[12:14] <mzanetti> so far 100%
[12:14] <tsdgeos> i have a tentative fix, let me push it and see if it fixes it for you
[12:14] <mzanetti> ack
[12:14] <tsdgeos> pull!
[12:17] <mzanetti> tsdgeos: pass
[12:18] <tsdgeos> good
[12:18] <tsdgeos> it's weird how something that was just a one off here was there all the time
[12:18] <mzanetti> yeah, I ran it as testDash
[12:18] <mzanetti> no xvfb
[12:19] <mzanetti> anyone knows where that "Using blocking call!!!" message is coming from?
[12:19] <mzanetti> I see that in my apps too
[12:20] <mzanetti> ok. passes in xbfb too. fixes the issue
[12:21] <Saviq> mzanetti, never saw that
[12:21] <Saviq> but judging by the 3 exclamation marks... Wellark ↑? ;P
[12:21] <mzanetti> lol
[12:22] <mzanetti> actually it's just one... the double ll! gave me that impression
[12:22] <Saviq> rofl
[12:22] <mzanetti> *that* funny?
[12:24] <greyback__> Saviq: wdyt, enough? Or should I implement a signal to be emitted to unity8, so unity does the sigstop: https://code.launchpad.net/~gerboland/qtmir/emitSigstopAtCorrectTime/+merge/244570
[12:25] <Saviq> greyback__, good enough for now
[12:25] <greyback__> yep, thought was enough for patch
[12:25] <Saviq> greyback__, later I want to be more granular
[12:25] <greyback__> sure
[12:25] <Saviq> greyback__, but that might as well wait for systemd
[12:25] <greyback__> that'll fix everything
[12:26] <Saviq> yeah, we'll be done then
[12:28] <mzanetti> tsdgeos: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293/comments/603140
[12:28] <tsdgeos> mzanetti: honestly i think it's testing again that qml bindings work
[12:28] <tsdgeos> but i can make it happen
[12:29] <mzanetti> tsdgeos: I'm rather thinking of the chain of qml bindings... if it's just easy please add a small one. if you need to start with creating a mock framework, it's probably not worth it
[12:30] <mzanetti> tsdgeos: a small glitch I just noticed: go to manage dash, click on a temp scope, see how the arrow label at the bottom slides in and fades out... probably shouldn't do that
[12:30] <mzanetti> not related to the above branches I think
[12:30] <tsdgeos> should be fine
[12:30] <tsdgeos> yeah i saw that the other day
[12:31] <tsdgeos> it's a thing between setting the scope and bla bla
[12:31] <tsdgeos> could be fixed
[12:31] <tsdgeos> mzanetti: would you mind creating a bug for me?
[12:31] <mzanetti> sure
[12:31] <tsdgeos> tx
[12:32] <Saviq> tsdgeos, did you notice how the scope header icons go transparent when you start dragging from the bottom?
[12:33] <mzanetti> tsdgeos: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1401869
[12:33] <tsdgeos> Saviq: i'd say is because of the disabling
[12:33] <mzanetti> Saviq: gotta go for an hour. I've tested this branch, works fine: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293
[12:33] <mzanetti> Saviq: however, we agreed to add a mock and test for it
[12:33] <mzanetti> Saviq: so once that's there, feel free to approve
[12:33] <tsdgeos> Saviq: not sure how that would be fixed
[12:34] <mzanetti> the other branch is approved already
[12:34] <Saviq> tsdgeos, right, makes sense
[12:34] <Saviq> mzanetti, yeah, thanks, I'll take over now
[12:34] <mzanetti> kk. see you in a bit
[12:38] <Saviq> Cimi, you there?
[12:41] <tsdgeos> mzanetti: Saviq: wops, actually yep, i think it's wrong ^_^
[12:41] <dandrader> Saviq, ubuntu-ui-toolkit with my dialog changes have landed, btw
[12:41] <Saviq> dandrader, coolz
[12:42] <dandrader> Saviq, bumped unity8 dependency accordingly
[12:42] <Saviq> dandrader, I don't think you should have
[12:42] <Saviq> dandrader, as you said, it's not actually a requirement
[12:42] <Saviq> dandrader, like things will work without it
[12:42] <Saviq> dandrader, and then improve when you get new UITK
[12:43] <Saviq> dandrader, what I mean by that is dependencies generally represent hard requirements
[12:44] <dandrader> Saviq, right... but does it do any harm? "make tryDialogs" look proper at least
[12:44] <dandrader> (with the new uitk)
[12:44] <dandrader> when you rotate things
[12:44] <Saviq> dandrader, do the test depend on the new UITK?
[12:45] <Saviq> dandrader, the "harm" is unnecessary packaging changes, and suggesting that things won't work otherwise
[12:45] <dandrader> Saviq, no strictly. but it will *look* broken without it
[12:45] <dandrader> well, I will revert it then
[12:46] <dandrader> Saviq, done
[12:47] <Saviq> dandrader, thanks
[12:47] <Wellark> Saviq, mzanetti: what!?
[12:47] <Wellark> :)
[12:48] <Wellark> where is that message?
[12:48] <Saviq> Wellark, log output from apps sometime
[12:48] <Saviq> greyback, I'll pop qtmir into the silo as well
[12:49] <Saviq> ah no, you have one already
[12:49] <Wellark> Saviq: well, I could write something like that, sure
[12:49] <Saviq> greyback, did you ping folks for publishing silo 14?
[12:49] <Wellark> but I usually augment my shit with a __PRETTY_FUNCTION__ or something :)
[12:57] <cwayne_> anyone have an idea why this renderer wouldn't show up with a background? http://paste.ubuntu.com/9488814/
[13:04] <Saviq> lol
[13:04] <Saviq> cwayne_, bug #1393008
[13:04] <Saviq> cwayne_, horizontal == no shape == no background, per spec
[13:04] <Saviq> that is
[13:04] <Saviq> (horizontal - summary) == no shape
[13:05] <tsdgeos> mzanetti: Saviq: ok, make this work https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244578 good call for testing ;)
[13:06] <tsdgeos> now food!
[13:14] <greyback> Saviq: I just set as tested, I didn't ping
[13:15] <Saviq> greyback, yeah, it helps to ping, gets them off their a$$es quicker
[13:15] <Saviq> greyback, but I think we're low on landing team atm
[13:15]  * Saviq hates to be blocked by that
[13:15] <greyback> Saviq: ok, wasn't aware, but wasn't in rush either
[13:17] <greyback> Saviq: I removed one qtmir branch you added, as it's caused visual errors. Forgot to set it unapproved, done now
[13:18] <Saviq> greyback, ok thanks
[13:19] <cwayne_> Saviq, oh, is that new? this renderer used to work (even if it shouldn't have :P)
[13:20] <Saviq> cwayne_, no, the spec is old, we might just not have enforced it until recently (due to some refactoring)
[13:20] <cwayne_> right, that's what i meant
[13:20] <cwayne_> i know the specs haven't changed recently :)
[13:21] <cwayne_> but ok, so if i add even a blank summary it should work then?
[13:21] <Saviq> cwayne_, yeah I think so
[13:21]  * Saviq checks
[13:21] <cwayne_> didn't seem to work for me, hm
[13:22] <Saviq> cwayne_, on that note, yeah
[13:22] <Saviq> cwayne_, so there's the bug
[13:22] <Saviq> cwayne_, it should work where there is summary
[13:23] <cwayne_> hm, damnit
[13:23] <cwayne_> ok
[13:28] <Saviq> greyback, should we drop the ::started() altogether then?
[13:28] <Saviq> greyback, or is there no default impl?
[13:32] <ChrisTownsend> Hmm, seems I'm not getting any scopes in the scope window on the new Unity 8 desktop mode.
[13:33] <ChrisTownsend> Sits there with the circle turning.
[13:35] <greyback> Saviq: empty implementation in keeping with the other empty listeners in the file. Could probably remove the listener class entirely, but that for later MR IMO
[13:36] <greyback> Saviq: and anyway yeah, no default impl
[13:36] <Saviq> greyback, kk
[13:37] <ChrisTownsend> After closing the window and letting unity8-dash restart, it's now to a window that has no scopes.  This is the unity8-dash log after restarting: http://pastebin.ubuntu.com/9489239/
[13:37] <ChrisTownsend> Saviq: Any ideas? ^^^^
[13:38] <Saviq> ChrisTownsend, is scope-registry running?
[13:39] <ChrisTownsend> Saviq: Is "scope-registry" the name of the process?  If so, then no.
[13:40] <Saviq> ChrisTownsend, it's an upstart job
[13:40] <Saviq> ChrisTownsend, process is, you guessed "scoperegistry"...
[13:41] <ChrisTownsend> Saviq: Yes, "scoperegistry" is running.
[13:41] <Saviq> ChrisTownsend, 'gsettings get com.canonical.Unity.Dash favorite-scopes'?
[13:42] <ChrisTownsend> Saviq: Output:
[13:42] <ChrisTownsend> $ gsettings get com.canonical.Unity.Dash favorite-scopes
[13:42] <ChrisTownsend> @as []
[13:42] <Saviq> ChrisTownsend, wonder how you got there
[13:42] <Saviq> ChrisTownsend, bottom swipe in the dash and add scopes to favorites
[13:43] <ChrisTownsend> So it seems it's empty.  How did that happen.  I only did a dist-upgrade and this is what happened.  It was fine yesterday in the pre-window mode.
[13:43] <Saviq> ChrisTownsend, you can `gsettings reset` it, too
[13:44] <ChrisTownsend> Saviq: I'll try that.
[13:44] <Saviq> ChrisTownsend, I just dist-upgraded my -next vm and that didn't happen, not sure how you got to that state :/
[13:45]  * ChrisTownsend shrugs
[13:46] <Saviq> greyback, btw, we could use a test for that sigstop... any idea how to attack that?
[13:47]  * greyback thought u8 had one
[13:47] <greyback> autopilot/unity8/shell/tests/test_upstart.py
[13:49] <ChrisTownsend> Saviq: fyi, the reset worked, so we'll chalk it up to an anomaly for now.  Thanks for your help.
[13:49] <Saviq> greyback, yeah, but that doesn't test the timing of it
[13:49] <Saviq> ChrisTownsend, sure, thanks
[13:50] <Saviq> greyback, we'd need to somehow add there a check that appmanager is ready when sigstop is emitted
[13:52] <greyback> Saviq: hmm, would need way for AP to be notified when AppMan is created. Am not sure how to do that with AP
[13:52] <Saviq> greyback, as long as we get a signal/property, we can wait for that
[13:53] <Saviq> greyback, on the AppManager object, that is
[13:53] <Saviq> greyback, just tell me what to wait for and I'll hack the test up
[13:56] <greyback> Saviq: there is no signal emitted by AppMan on construction. Only idea I have is figuring out what its parent object will be, and listening for children being added to it to see if one is AppMan
[13:57] <Saviq> greyback, it doesn't have Component.onCompleted does it
[13:58] <Saviq> greyback, and it's a singleton, its parent is the plugin...
[13:58] <greyback> Saviq: the qml engine might attach that property to it, I've never had that thought
[13:59] <Saviq> stupid, I'll get the onCompleted of the Connections object...
[14:00] <Saviq> or nothing, for that matter
[14:00] <Saviq> oh ok, that's all not gonna work, AP does polling
[14:01] <Saviq> so before it gets an object, the process is going to stop
[14:01] <Saviq> greyback, ok, I'll have to chat with QA folk on that
[14:01] <greyback> yeah, it's kinda tricky
[14:05] <greyback> 34 tag(s) updated. - uh ohs, is qtmir getting infected
[14:23] <mterry> If I wanted to have a tst_XXX.qml file that ran ALL tests against two different configs (like a constant _data() for each test function), is there an easy way to do that without actually specifying the _data() methods?
[14:28] <dandrader> mterry, that's for you: https://code.launchpad.net/~dandrader/unity8/unifyLightDMMocks/+merge/244593
[14:28] <Saviq> mterry, other than making the _data() a wrapper returning some common data set, not that I know of
[14:30] <dandrader> mterry, I thing you could create a separate component inheriting from UnityTestCase and instantiate it twice you your tst_Foo.qml
[14:30] <dandrader> s/thing/think
[14:30] <Saviq> dandrader, I think he wants to share the _data between different test_ functions, too
[14:30] <dandrader> mterry, like MyTestCace { foo: "this" } MyTestCase { foo: "that" }
[14:33] <dandrader> Saviq, he wouldn't use the _data feature in that case, but would achieve the same result
[14:34] <mterry> dandrader, but wouldn't I have to specify each test_ function twice?
[14:35] <dandrader> mterry, the "foo" property in the example would be the config you want all tests in the TestCase to use
[14:36] <mterry> dandrader, sure sure but say I have a test like test_foo().  Wouldn't I have to put that inside both MyTestCase objects?
[14:36] <dandrader> mterry, no, you would write it only once in MyTestCase.qml
[14:37] <dandrader> mterry, you would treat the testcase just like any other qml component
[14:37] <mterry> dandrader, oh I see.  A very specific MyTestCase
[14:37] <mterry> I was thinking you were suggesting a generic mechanism.  But that could work well yeah
[14:37] <dandrader> mterry, yeah, like a ShellTestCase.qml
[14:37] <dandrader> used only by tst_Shell.qml
[14:53] <dandrader> mterry, since you changed the approach, you should update the commit message of https://code.launchpad.net/~mterry/unity8/power-button-on-lock/+merge/239076
[14:53] <mterry> dandrader, ah yes
[14:53] <mterry> dandrader, ah naive young me: "Making the GreeterContent loader asynchronous seems like an easy fix."
[14:53] <dandrader> :D
[14:55] <mterry> dandrader, done
[14:55] <dandrader> mterry, thanks
[14:55] <mterry> dandrader, and I saw your unify branch, will get to it today
[14:55] <dandrader> mterry, awesome. thanks
[15:20] <dandrader> mzanetti, will start working on the mouse task now. what is it exactly?
[15:21] <dandrader> mzanetti, is that unity8 is not getting or forwarding mouse events to apps?
[15:21] <mzanetti> dandrader: we don't get mouseMoveEvents
[15:21] <mzanetti> dandrader: not even to apps only. even inside unity
[15:21] <mzanetti> dandrader: to test do this:
[15:21] <dandrader> mzanetti, right
[15:21] <mzanetti> MouseArea { hoverEnabled: true; onMouseXChanged: print("it works!");  }
[15:22] <mzanetti> dandrader: and then make it print "it works!" without clicking :)
[15:22] <dandrader> mzanetti, we don't get *any* mouse events at all right? (no button presses or anything)
[15:22] <mzanetti> dandrader: well, we do get that, but can't distinguish between mouse or tap I think
[15:23] <mzanetti> dandrader: that's not really critical at this point in time. the mouse hovering is more important as a first step
[15:23] <mzanetti> and I guess by then you'll have figured what exactly is missing
[15:24] <dandrader> mzanetti, interesting. I would guess it would be an all-or-nothing for mouse events
[15:24] <dandrader> mzanetti, so, I have to setup that mir+unity8 in a VM thing
[15:24] <mzanetti> dandrader: interestingly I do even get mouse scroll events in the vm
[15:24] <greyback> right/middle click & scrollwheel would be nice too
[15:25] <mzanetti> dandrader: you can choose between a VM or just setting up a second user
[15:25] <mzanetti> however, switching vt might hang your computer... so a VM is desirable from that pov
[15:25] <mzanetti> otoh, the VM is slower
[15:25] <mzanetti> greyback: strangely I do get those
[15:25] <dandrader> mzanetti, but is it slow to be point of being unusable?
[15:25] <mzanetti> greyback: two-finger scroll on a touchpad at least
[15:25] <mzanetti> dandrader: no. it usable
[15:26] <greyback> mzanetti: yeah I am surprised. It's not implemented in the code anyway
[15:26] <mzanetti> dandrader: no. it is usable
[15:26] <mzanetti> dunno :D
[15:26] <greyback> it's better than the emulator :)
[15:27] <mterry> dandrader, in the unify branch, the demo plugin shares some code with the liblightdm mock.  Any chance they could actually share the file?  Like have the mock version subclass the demo version or something?  Also, we've been meaning to rename the demo plugin because we are actually using it in producton now
[15:27] <greyback> I'm told this works now too, if you have the 3.18 kernel: http://unity.ubuntu.com/mir/setup_kvm_for_mir.html
[15:30] <dandrader> mterry, ok, I will look into it
[15:31] <dandrader> mterry, so, should I rename the plugins/LightDM/demo dir to something else
[15:47] <kgunn_> mterry, looks like you're having internet fun, so you prolly missed it....can greeter be made to "scroll up a bit" in the case where keyboard is covering the text box ?
[15:47] <mterry> kgunn_, this is when rotated?  I thought we didn't rotate the greeter
[15:48] <kgunn_> mterry, so on n7, greeter in landscape
[15:48] <kgunn_> fixed
[15:48] <kgunn_> can't see how many characters i've entered
[15:48] <mterry> kgunn_, oh when in tablet mode?
[15:48] <kgunn_> right
[15:48] <mterry> curious
[15:48] <mterry> kgunn_, well yes the answer is we can...  would take a little work but sure -- we never ran into that before?  huh
[15:49] <mterry> kgunn_, does design have opinions on how that should look?  (like just shift everything up?  rotate name up in list?  something else)
[15:49] <kgunn_> mterry, yeah, ppa:unity-team/demo-stuff on vivid n7 shows the example
[15:50] <kgunn_> mterry, no input from design...more about having something workable for mwc
[15:50] <mterry> kgunn_, ah ok
[15:51] <mterry> kgunn_, so this is relatively high priority
[15:52] <mterry> kgunn_, is there a bug?
[15:53] <kgunn_> mterry, only on the team punch list...not on lp
[15:53] <kgunn_> https://docs.google.com/a/canonical.com/spreadsheets/d/140Icn5zcZwMvg1SONrwRKXYip-Pie7jtbEARpWwgxfw
[15:53] <mterry> kgunn_, I'll make one and assign to me
[15:53] <kgunn_> ack
[15:55] <kgunn_> mterry, wait.... dandrader|lunch might have fixed this?
[15:56] <mterry> kgunn_, he was doing rotation work...  I don't recall him mentioning a fix for this, but that would be a nice bonus!
[15:56] <kgunn_> mterry, yeah...hmmm, dunno what changed, but i can see the text box....looks like he resized the osk ?
[15:56] <mterry> kgunn_, dandrader|lunch: well https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1401951
[15:57] <mterry> kgunn_, I guess mark in progress then?  His branch is cleared to land if I recall
[15:58] <kgunn_> ack
[16:07] <willcooke> Saviq, heyhey - can you tell me the magic incantation to get wm working?  I have to modify Shell.qml ?
[16:08] <tsdgeos> greyback: not thrilled about it, but seems to work https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622
[16:08] <greyback> willcooke: 	gsettings set com.canonical.Unity8 usage-mode Windowed
[16:09] <willcooke> Saviq, scratch that.  Just works
[16:09] <willcooke> thx greyback
[16:09] <tsdgeos> greyback: will gladly accept architectural suggestions
[16:09] <greyback> tsdgeos: will have a look, thanks
[16:09] <seb128> willcooke, greyback, Saviq: I updated ubuntu-settings to set that key on desktop, should work out of the box with vivid from today
[16:09] <seb128> on desktop-next
[16:09] <greyback> seb128: ah nice
[16:09] <willcooke> seb128, \o/
[16:10] <seb128> willcooke, I mentioned it early on #ubuntu-desktop btw, but I guess you didn't follow the channel today :-)
[16:10] <seb128> willcooke, feeling better btw?
[16:10] <willcooke> seb128, not really, but rickspencer3 is a slave driver :)
[16:12] <seb128> lol
[16:45] <kgunn_> mzanetti, so should seb at a toggle for windowed vs full screen shell mode ?
[16:46] <mzanetti> kgunn_: where?
[16:46] <kgunn_> in system settings
[16:46] <kgunn_> just thinking...maybe a user might wanna override
[16:46] <mzanetti> hmm... not sure we want that
[16:46] <kgunn_> back to hypoth-generator
[16:46] <mzanetti> yeah... I guess it would a good task to figure what we want the user to be able to change
[16:49]  * greyback eow
[16:49] <greyback> o/
[16:50] <Saviq> o/