[08:14] <tsdgeos> Saviq: ping
[08:14] <Saviq> tsdgeos, hey
[08:14] <Saviq> I know, pstolowski didn't run our autopilot tests, naughty naughty
[08:14] <tsdgeos> Saviq: that's not what i wanted :D
[08:14] <Saviq> ;)
[08:14] <tsdgeos> Saviq: was wondering if in the CI results
[08:14] <pstolowski> huh?
[08:15] <Saviq> pstolowski, see the yellow? https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=phone-armhf,release=vivid+overlay,testname=autopilot.sh/ :)
[08:15] <tsdgeos> you could prepend the type of job before the SUCCESS/UNSTABLE/FAILURE
[08:15] <tsdgeos> so it'd be muuuuuuuuuuuuuuch easier to parse
[08:15] <Saviq> tsdgeos, type of job? you mean whether it's build or test or whatnot?
[08:15] <tsdgeos> yeah
[08:15] <tsdgeos> Compile arm:
[08:16] <tsdgeos> Run qmluitests:
[08:16] <tsdgeos> Run autopilot:
[08:16] <tsdgeos> etc
[08:16] <Saviq> tsdgeos, problem is that would mean even more text than today, since we want the links still, don't we?
[08:16] <tsdgeos> sure sure, the links are needed
[08:17] <Saviq> maybe we can shorten them :)
[08:17] <pstolowski> is this after single-preview landed?
[08:17] <Saviq> pstolowski, yeah
[08:17] <pstolowski> crap
[08:18] <tsdgeos> the problem is that if you see https://code.launchpad.net/~lukas-kde/unity8/pinLockHWKeyboard/+merge/287327/comments/734786
[08:18] <tsdgeos> it takes time to know what's wrong (in case one of them was a failure)
[08:18] <Saviq> pstolowski, we'll deal with that, nw - our fault, too, since nobody paid attention
[08:18] <Saviq> tsdgeos, sure, I think the real problem is the links there
[08:19] <pstolowski> Saviq, why didn't it manifest itself in the silo before landing?
[08:19] <Saviq> pstolowski, because those are AP tests, only run on phones
[08:19] <Saviq> and no phones in the train
[08:19] <Saviq> tsdgeos, if you had SUCCESS/FAILURE just under one another, you could see the diff easier
[08:20] <Saviq> tsdgeos, like see an email from unity8-ci-bot in your inbox, that's much easier to parse, 'innit?
[08:20] <Saviq> you go top-down, notice FAILURE or UNSTABLE and you get the link
[08:20] <Saviq> tsdgeos, don't get me wrong, I know this is suboptimal
[08:20] <tsdgeos> but i'd still have to parse if the SUCCESS/FAILURE is because it failed to compile or a qmluitest or autopilot
[08:20] <Saviq> just have no good idea of making it better just yet
[08:21] <Saviq> tsdgeos, from the link you mean?
[08:21] <tsdgeos> for branches that are not mine depending what fails i care more and click the link or care less and don't :D
[08:21] <tsdgeos> Saviq: yeah
[08:21] <Saviq> tsdgeos, I'll think what can be done
[08:22] <tsdgeos> cool, thanks :)
[08:22] <tsdgeos> Saviq: anyone working on fixing those ap tests?
[08:22] <Saviq> tsdgeos, not just yet, was waiting to slap cimi on the wrist when he comes around ;)
[08:23] <tsdgeos> my fault too since i top approved it
[08:23] <tsdgeos> didn't really remember we had tests there
[08:23] <pstolowski> tsdgeos, we'll need to bump versions in the filters stuff after recent landings, on it, will yet you know
[08:23] <Saviq> yeah, well, if we had CI :P
[08:23]  * Saviq has ideas about CI for MPs relying on other MPs
[08:24] <Saviq> truth be told it's sounding a lot like I'm reimplementing half of the train by now...
[08:30] <tsdgeos> :D
[09:01] <Saviq> greyback, w00t!
[09:01] <Saviq> can't sleep, can ya? :)
[09:02] <greyback> so excited to be back
[09:02] <Saviq> greyback, how's your world look?
[09:03] <greyback> Saviq: pretty good. Bit blurry still, bright lights at night are more intense too
[09:04] <greyback> overall, worth it
[09:04] <Saviq> so you feel the improvement already?
[09:04] <tsdgeos> greyback: welcome back
[09:06] <greyback> Saviq: well, aside from not needing glasses any more, it's not a giant improvement
[09:06] <Saviq> wasn't that the whole point? :D
[09:06] <greyback> the blurriness will take time to go, then I should be 20:20
[09:06] <greyback> it was
[09:07] <greyback> it's a load of little things, adding up, which makes it good
[09:08] <greyback> tsdgeos: thanks!
[09:46] <tsdgeos> Saviq: i'm with you that Preview::test_ComboEnsureVisible seems that something would be wrong in ListView::positionViewAtIndex, going to have a look
[09:58] <Saviq> tsdgeos, tx
[10:34] <ShabbyII> hi
[10:41] <Saviq> well hello
[11:19] <tsdgeos> Saviq: so the problem with test_ComboEnsureVisible is a race, basically the list is not "big enough" yet when we call positionViewAtIndex
[11:19] <tsdgeos> Saviq: so i can fix it (or at least hasn't failed in a good while)
[11:19] <tsdgeos> with a call to forceLayout(); before positionViewAtIndex and making forceLayout actually force the layout a bit more inside Qt
[11:20] <Saviq> tsdgeos, oh cool, I've been using parallel to melt my CPU a bit with 10 of those tests running at the same time and it failed quite quickly
[11:21] <Saviq> tsdgeos, so we should be able to see if that helps
[11:21] <tsdgeos> problem is that it needs a patch to Qt :D
[11:21] <tsdgeos> i am almost positive it's good
[11:21] <Saviq> oh so we can forceLayout from QML?
[11:21] <Saviq> while parallel -i -j10 make -C builddir testPreview -- 1 2 3 4 5 6 7 8 9 0; do :; done
[11:21] <tsdgeos> yes forceLayout is exported
[11:21] <Saviq> add xvfb if you don't wanna see
[11:21] <tsdgeos> but it doesn't *really* force a layout
[11:21] <Saviq> lol
[11:22] <tsdgeos> yeah
[11:22] <tsdgeos> what it does now is
[11:22] <tsdgeos> if (isComponentComplete() && d->currentChanges.hasPendingChanges())
[11:22] <tsdgeos>     forceLayout();
[11:22] <tsdgeos> what i changed it to is
[11:23] <tsdgeos> if ((isComponentComplete() && d->currentChanges.hasPendingChanges()) || d->forceLayout)
[11:23] <tsdgeos>         d->layout();
[11:23] <davmor2> Saviq: surely 0 is before 1 :P
[11:23] <tsdgeos> forceLayout is another internal flag that is set needing "we need to layout"
[11:23] <tsdgeos> naming is awesome as you can see
[11:23] <tsdgeos> going to propose this
[11:23] <tsdgeos> see how lucky i am
[11:23] <Saviq> davmor2, I don't like 0s
[11:24] <Saviq> tsdgeos, ack
[12:48] <dandrader> Saviq, "30 tag(s) updated.", looks like unity-api got contaminated by the tags virus...
[12:48] <Saviq> dandrader, everything everywhere is contaminated, TBH I think we should just come to terms with the fact we're not going to get rid of those in bzr
[12:49] <dandrader> Saviq, how's git integration with launchpad these days?
[12:49] <Saviq> dandrader, https://help.launchpad.net/Code/Git
[12:50] <Saviq> dandrader, the bit that's missing for our workflow is support in the train, but that's coming not long from now, too, robru's already working on it
[13:16] <cimi> pstolowski, tsdgeos new MR https://code.launchpad.net/~cimi/unity8/card-social/+merge/288287
[13:16] <tsdgeos> k
[13:17] <cimi> tsdgeos, changed prereq
[14:18] <tsdgeos> cimi: ping
[14:25] <cimi> tsdgeos, pong
[14:26] <tsdgeos> cimi: this ifelse looks weird http://paste.ubuntu.com/15321021/
[14:26] <tsdgeos> anything i'm missing or can we convert it to a single ifelse instead of two?
[14:28] <cimi> tsdgeos, you're right
[14:28] <cimi> is weird indeed
[14:29] <cimi> tsdgeos, http://paste.ubuntu.com/15321039/ committing
[14:29] <tsdgeos> tx
[14:30] <cimi> tsdgeos, done
[15:04] <Saviq> tsdgeos, ENOPARSE on the commit message in https://codereview.qt-project.org/#/c/151559/ :)
[15:04] <tsdgeos> Saviq: do you get confused because there's a d->forceLayout variable and a forceLayout function that don't do the same?
[15:04] <tsdgeos> or?
[15:05] <Saviq> tsdgeos, no, because the commit message seems to have a broken sentence in it :)
[15:05] <Saviq> "when for example an item the size
[15:05] <Saviq> that affects the item view content size"
[15:05] <tsdgeos> oh yeah
[15:06] <tsdgeos> missing verb in there
[15:06] <Saviq> yup :)
[15:07] <tsdgeos> Saviq: does that read better?
[15:07] <tsdgeos> This way callers of forceLayout get a relayout if the dimension
[15:07] <tsdgeos> of a delegate that affects the itemview content size has just happened
[15:07] <tsdgeos> but the itemview content size has not been updated yet.
[15:08] <tsdgeos> dimension -> geometry?
[15:08] <Saviq> tsdgeos, dimension/geomery...happened?
[15:08] <tsdgeos> bsically i want to say height/width if list is vertical/horizontal
[15:08] <Saviq> dimension's fine then
[15:08] <tsdgeos> changed
[15:08] <Saviq> yeah ↑
[15:08] <tsdgeos> man i'm broken today
[15:08] <tsdgeos> ok, let's go with that
[15:10] <cimi> tsdgeos, so I review filters now?
[15:10] <tsdgeos> cimi: yes
[15:10] <tsdgeos> pelase
[15:11] <tsdgeos> -e+e
[16:06] <cimi> tsdgeos, fixed the card social test
[16:06] <tsdgeos> cool, tx
[16:06] <tsdgeos> cimi: will you ask patricia about the carousel?
[16:06] <cimi> tsdgeos, I can now, however I dont think it makes sense to have something like a thumb up there
[16:07] <tsdgeos> why not?
[16:07] <cimi> too many input things in such a small space
[16:07] <tsdgeos> it's as big as a regular card
[16:07] <cimi> also you want to scroll, and tap to open, and tap to like?
[16:08] <tsdgeos> it's basically the same as the horizontal list
[16:08] <tsdgeos> and it works there ;)
[16:08] <cimi> tsdgeos, otherwise I might need to implement it inside overlay, not sure I did iirc
[16:09] <tsdgeos> cimi: it's not implemented no, and i see why it may be a problem, but we iether need to accept it won't work on carousels and document it or make it work
[16:09] <tsdgeos> silently doign it it's not nice
[16:09] <cimi> tsdgeos, fair enough
[16:12] <cimi> tsdgeos, answer is no, we dont want cause it will cause issues with input
[16:12] <cimi> tsdgeos, available only in grid/list
[16:12] <tsdgeos> cimi: so question is, right now they would appear if you add them, do we want to filter them out? or just document somewhere that they won't work and hope people won't use them?
[16:22] <cimi> tsdgeos, we can not show them from cardtool no?
[16:23] <cimi> and then yes we want to document
[16:23] <tsdgeos> cimi: i think that's what make more sense, even write a console.log() if that happens
[16:42] <dandrader> Saviq, hey. I'm about to propose surface-based WM
[16:43] <dandrader> Saviq, would you prefer it as a trio of huge MPs or a stack of smaller MPs with a slightly less huge MP on top?
[16:44] <dandrader> Saviq, stack/chain
[16:44] <dandrader> Saviq, s/trio of huge MPs/huge MP
[16:45] <dandrader> Saviq, (keeping the subject on unity8 only, not mentioning qtmir & unity-api)
[16:51] <Saviq> dandrader, stack/chain for easier review
[16:51] <dandrader> Saviq, pl
[16:51] <dandrader> Saviq, ok
[16:51] <Saviq> pl's fine ;P
[17:05] <ltinkl> dandrader, woo :) so who's gonna rebase his stuff? :p