[07:50] <Saviq> AlanBell, you need ppa:ubuntu-sdk-team for newest SDK
[07:57] <Saviq> MacSlow, o/ long time no see :)
[08:17] <Saviq> tsdgeos, \o
[08:17] <tsdgeos> Saviq: welcome, how was south africa?
[08:17] <Saviq> tsdgeos, hot and sunny ;)
[08:18] <Saviq> tsdgeos, now back home - 10° below 0 here ;)
[08:18] <tsdgeos> booo
[08:18] <Saviq> so ~ 40° degrees difference ;)
[08:18] <Saviq> -degrees
[08:18] <Saviq> tsdgeos, how was here?
[08:19] <tsdgeos> otto broke again
[08:19] <tsdgeos> and then fixed itself
[08:19] <tsdgeos> except for one particular test
[08:19] <tsdgeos> so we have all CI failing again
[08:19] <Saviq> tsdgeos, :/
[08:20] <Saviq> tsdgeos, fginther wrote that it disappeared with updates to lp:unity-scopes-api
[08:21] <tsdgeos> And i discovered the Qt 5.2 JS engine is totally broken in x86, but failed to get any traction from upstream to fix it https://codereview.qt-project.org/#change,76374 https://bugreports.qt-project.org/browse/QTBUG-36430 https://bugreports.qt-project.org/browse/QTBUG-36289
[08:21] <tsdgeos> Saviq: https://app.asana.com/0/9785046628744/9782553540311 is tracking the new one
[08:21] <tsdgeos> there's a new comment in there, i'll see if i can get it to fail doing what they say
[08:22] <Saviq> tsdgeos, apparently I don't have access to that  task or something - empty here
[08:22] <MacSlow> Saviq, hey :)
[08:24] <tsdgeos> Saviq: hmmm, there's a "Make public to canonical.com addresses, but not sure if the guys will get angry if i do that :D"
[08:24] <Saviq> tsdgeos, yeah, leave it to them
[08:24] <tsdgeos> Saviq: anyway, the interesting link was https://wiki.canonical.com/UbuntuEngineering/CI/Playbook/UpstreamMerger#Reproducing_generic-mediumtests-runner_touch_testing
[08:25] <Saviq> tsdgeos, mhm
[08:43] <Saviq> ricmm, o/ how's Londres?
[08:44]  * tsdgeos tries reproducing the otto failures with those instructions
[08:46] <tsdgeos> Mirv: ping
[08:48] <Mirv> tsdgeos: pong
[08:48] <tsdgeos> Mirv: seen my comments from friday about qtubuntu?
[08:48] <tsdgeos> in this channel
[08:49] <Mirv> tsdgeos: yes. not really sure why it'd be, but at least the qtdeclarative snapshot was added only after the last rebuild. so I triggered another rebuild, but I haven't got my device yet to the state of testing it.
[08:49] <tsdgeos> ok
[08:59] <mhr3> Saviq, heya, back from holidays?
[08:59] <Saviq> mhr3, yup, here
[08:59] <Saviq> mhr3, I saw you had some confusion with the preview JSONs in #ferrets?
[09:00] <mhr3> Saviq, yep can we talk in a bit?
[09:00] <mhr3> also thomas wants to join
[09:00] <mhr3> Saviq, in 30mins good for you?
[09:00] <Saviq> mhr3, sure, I've a half-hour at 11am/UTC, free until/past that
[09:01] <Saviq> mhr3, yeah
[09:03] <tsdgeos> Saviq: oh, so the blurry icons thing was already reported :D good thing i didn't know so i did actually look into it instead of just duplicating ^_^
[09:03] <Saviq> tsdgeos, ;)
[09:06] <Saviq> tsdgeos, I saw bug #1271676 creep up on us some time ago, feels like a LVWPH issue?
[09:06] <tsdgeos> Saviq: isn't that the expected behaviour?
[09:07] <tsdgeos> i mean you launch an app it shows the running apps
[09:07] <tsdgeos> i thought it was by design
[09:07] <Saviq> tsdgeos, not if you scrolled down
[09:07] <Saviq> tsdgeos, i.e. expand "Installed", scroll to the bottom, launch → it jumps to top
[09:08] <Saviq> should remain in place, IMO (and should definitely *not* jump in just one frame)
[09:09] <Saviq> pete-woods, hey, any idea how https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7 might happen?
[09:09] <pete-woods> Saviq: perhaps if the XDG_DATA_DIR environment variable was messed up somehow?
[09:09] <Saviq> pete-woods, and whether we could/should protect against it?
[09:10] <Saviq> pete-woods, hmm
[09:10] <tsdgeos> Saviq: ah ok
[09:10] <tsdgeos> Saviq: i can have a look then
[09:10] <pete-woods> Saviq: I guess that must be where gsettings-qt looks for the schemas..
[09:10] <tsdgeos> Saviq: let me try reproducing the autopilot/otto errors first though
[09:10] <Saviq> tsdgeos, of course
[09:11] <pete-woods> but why does it log fatal? seems a bit dramatic
[09:11] <Saviq> pete-woods, that's G
[09:12] <pete-woods> true!
[09:12] <Saviq> pete-woods, you need to check for a schema to exist before trying to load it
[09:12] <pete-woods> Saviq: okay, that's a good idea, I'll try and figure out how to do that with the API
[09:13] <Saviq> pete-woods, I think it'd need to be gsettings-qt that needed changing, TBH
[09:13] <Saviq> larsu, WDYT? https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7
[09:13] <Saviq> larsu, protect against crash because of missing schema in gsettings-qt?
[09:19] <larsu> Saviq: ah, the old discussion :)
[09:20] <Saviq> larsu, I imagine it is ;)
[09:20] <larsu> Saviq: why is this happening. Is unity supposed to work even when UserMetrics is not installed?
[09:20] <Saviq> larsu, we don't yet know the reason, but yes it should
[09:21] <Saviq> larsu, as I haven't seen anyone reproduce it
[09:21] <larsu> Saviq: right. In that case, I think we should have a way to find out if it is installed
[09:21] <larsu> because which values of which types should gsettings-qt return if the schema is not installed?
[09:22] <larsu> probably unity would crash anyway (or behave weirdly) if we just returned empty variants
[09:22] <Saviq> larsu, undefined, probably ;)
[09:22] <Saviq> well, it looks like they're really old installations - unity8 from Oct 16, and I don't know of a way to reproduce...
[09:23] <larsu> Saviq: uninstall UserMetrics probably :)
[09:24] <Saviq> larsu, well, yeah, :P
[09:24] <Saviq> larsu, I mean not sure how that happens to people
[09:25] <larsu> Saviq: usermetricsservice (the package that contains the schema) is not a dependency of unity8
[09:25] <Saviq> mzanetti, oi man o/
[09:26] <Saviq> larsu, it is through libusermetricsoutput1
[09:26]  * greyback waves
[09:26] <larsu> Saviq: ah, through unity8-private, thanks. Well in that case the bug can't happen and we should ignore it :P
[09:27] <Saviq> larsu, yeah indeed
[09:28] <Saviq> greyback, \o got home OK?
[09:28] <Saviq> greyback, how long at the airport before you could check in?
[09:28] <greyback> Saviq: yep, home ok. I managed to check in at 6.30, so wasn't long wait
[09:28] <Saviq> greyback, good
[09:49] <Mirv> tsdgeos: confirming qt 5.2 unity8 now runs. apps lens seems to be empty, and starting an app from the home lens does not work, but all in all seeing unity8 itself smooth and working looks really nice.
[09:49] <tsdgeos> Mirv: i had the apps lens i think
[09:49] <Mirv> it seems I'm able to launch stuff via indicators, like battery view
[09:50] <tsdgeos> but maybe not
[09:50] <tsdgeos> don't really remember
[09:50] <Mirv> yeah, system settings etc works via indicators, just not via normal app launchers
[09:50] <Mirv> Saviq: welcome back, and sorry for the highlighting noise :)
[09:53] <Mirv> Saviq: so this actually works now. http://pastebin.ubuntu.com/6808355/ - the qtmultimedia-touch packaging does not clean itself up, otherwise those lines wouldn't be needed
[09:53] <Saviq> Mirv, hey, no worries
[09:54] <Saviq> Mirv, cool beanz
[10:09] <Saviq> tsdgeos, 2:30pm for a hangout about CI train?
[10:10] <tsdgeos> Saviq: it's a bit tight with my lunch schedule but should work
[10:11] <Saviq> tsdgeos, no that's fine
[10:11] <Saviq> tsdgeos, say when
[10:11] <tsdgeos> 3pm is a bit better
[10:11] <tsdgeos> s/bit//
[10:13] <Saviq> tsdgeos, ok, half an hour should do I think, mzanetti ↑
[10:13]  * Saviq does invite
[10:14] <mzanetti> still fine with me
[11:06] <tsdgeos> bah
[11:06] <tsdgeos> took me ages to setup that thing for autopilot
[11:06] <tsdgeos> just to have it still succeed
[11:06] <tsdgeos> :D
[11:06] <tsdgeos> :'(
[11:09] <Saviq> :/
[11:11] <tsdgeos> Saviq: do we know if the QA phones use trusty or trusty-proposed?
[11:11] <tsdgeos> we do
[11:11] <tsdgeos> because it upadtes
[11:11] <Saviq> tsdgeos, good question
[11:11]  * tsdgeos checks
[11:12] <tsdgeos> doesn't seem to use -proposed
[11:12] <tsdgeos> wonder if that is the case since i'm using it
[11:13] <tsdgeos> let me flash the phone with trusty only and see if it fails then
[11:13] <Saviq> tsdgeos, hmm I'm seeing -proposed http://s-jenkins.ubuntu-ci:8080/job/touch-flash-mako-0090f741e3d141bc/792/console
[11:13] <tsdgeos> Saviq: but https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2266/consoleFull ?
[11:13] <Saviq> tsdgeos, otto is on x86
[11:13] <Saviq> tsdgeos, no images there
[11:14] <tsdgeos> is it?
[11:14] <Saviq> tsdgeos, yup
[11:14] <tsdgeos> and why am i pointed at stuff running on the phone?
[11:14] <tsdgeos> sigh
[11:14] <Saviq> "ps-nvidia-gt630"
[11:14] <Saviq> is what this job run at
[11:14] <tsdgeos> ok
[11:15] <mhr3> question, if i pass a qobject without a parent to qml, will it take ownership of it by calling setParent()?
[11:16] <tsdgeos> what's "pass a qobject" ?
[11:16] <Saviq> mhr3, ownership, not parentship
[11:17] <Saviq> mhr3, I don't think it will assign a parent...
[11:17] <tsdgeos> so i will try yet again on my desktop just for the fun
[11:17] <Saviq> tsdgeos, return from a model, for instance
[11:17] <tsdgeos> no, won't call setparent at all
[11:17] <mhr3> in that case the model we're using is kinda broken
[11:18] <Saviq> mhr3, meaning?
[11:18] <mhr3> we construct a preview before emitting previewReady() with the preview as a param, if there was noone listening to that signal the instance would leak
[11:22] <mhr3> and setting the scope as the preview parent doesn't seem to be helpful unless shell notified the plugin everytime it's done with a preview
[11:26] <mhr3> sounds like the correct way to do this would be to return an object from the preview() request itself and have a finished() signal on that when all the data is ready
[11:29] <tsdgeos> so yeah, oran again the tests on my machine and still work _:'(
[11:48] <karni> Saviq: Welcome back :)
[11:48] <Saviq> karni, hey, how are you?
[11:48] <karni> Saviq: Not bad, thanks :) Rested after your holiday? :)
[11:49] <Saviq> karni, when have you last rested on holidays, I ask you?
[11:49] <Saviq> ;)
[11:49] <karni> Saviq: honestly, had to take last Thursday off. We're not that long after christmas, are we? haha
[11:50] <Saviq> karni, I rather meant that I could usually use another week or two to actually rest past the holiday part ;)
[11:51] <karni> Saviq: I found that ResponsiveGridView margins always evaluate to 0, and all columns have spacing to its right (including the last one), which is clearly visible when you do tryFilterGrid. That was highly confusing :S
[11:51] <karni> Saviq: hahahahahah right ;)
[11:51] <karni> Sometimes I don't get the simplest jokes lol
[11:51] <Saviq> karni, that's right, the tiles themselves need to center themselves
[11:52] <Saviq> karni, as the Grid doesn't actually change the size of the delegates
[11:52] <karni> Saviq: Does Card(.qml) center itself? i.e. the renderer should not care?
[11:52] <Saviq> karni, no, it doesn't indeed
[11:52] <Saviq> karni, but there's more - Card doesn't know about the size it "should" be
[11:53] <Saviq> karni, so it's CardFilterGrid that should wrap the Card in an Item, that will be sized accordingly
[11:53] <Saviq> karni, and which will center the Card inside of itself
[11:53] <karni> I see. And about margins - if they always evaluate to zero - does that mean we're not interested in ResponsiveGridView margins? If so, I'd like to remove those bits. I tried to make them work, which resulted in really strange behavior of 2 columns always displaying as one, as if there was not enough space (all worked fine for 3+ number of columns)
[11:54] <karni> Saviq: That makes sense. I wonder if that's the case already, I recall CardFilterGrid had "Card" as delegate
[11:54] <Saviq> karni, which was probably a fail on my part
[11:54] <karni> aha
[11:55] <karni> Saviq: I understand that I should drop the "margin" evaluating code from ResponsiveGridView, because they always (mathematically) resolved to zero width.
[11:56] <Saviq> karni, if you can confirm they did, yeah
[11:56] <Saviq> karni, but I'm not entirely sure that's correct
[11:57] <karni> Saviq: I'll find that and let you know.
[11:57] <Saviq> karni, thanks
[11:57] <karni> sure
[11:58] <Saviq> karni, yeah, if I resize the window, I get them to be 8/14 or something
[11:59] <Saviq> karni, I mean onMarginsChanged: console.log(margins) in ResponsiveGridView
[11:59] <Saviq> karni, prints different values, depending on the size of the window
[12:00] <karni> Interesting.
[12:07] <karni> Saviq: ok, let's start elsewhere. qml/Components/ResponsiveGridView.qml ln 73 columnsForSpacing function - the formula should be return Math.max(1, Math.floor(parent.width / (delegateWidth + spacing)));
[12:07] <karni> Saviq: me and tsdgeos agree on that, I just wanted for you to validate.
[12:07] <karni> Saviq: if margin is half of spacing, then we should divide parent.width over (delegateWidth + spacing)  -- the last spacing is spread over two margins.
[12:08] <karni> There's no reason anything would be subtracted from parent.width before division.
[12:08] <karni> Is there.
[12:12] <Saviq> karni, spacing is only applied on one side of the delegate, so I feel like it does make sense
[12:13] <Saviq> karni, taking "// minimum margin is half of the spacing" into account
[12:13] <karni> Saviq: and by "margin" the author meant "sum of left and right" margins?
[12:14] <tsdgeos> Saviq: spacing is only applied in one side of the delegate?¿
[12:14] <karni> 2x spacing/2 = spacing. n-1 columns have spacing. n*(delegateWidth + spacing) would make n columns, n-1 spacings, and 1 spacing being both margins.
[12:14]  * Saviq needs a drawing
[12:14] <karni> Saviq: sending it to you
[12:15] <karni> Sent.
[12:15] <Saviq> tsdgeos, in RGV we're not *really* using GridView's spacing
[12:15] <tsdgeos> Saviq: what are we using?
[12:16] <Saviq> tsdgeos, nothing, we're just telling the delegates to center within themselves
[12:16] <Saviq> tsdgeos, and tell them their size
[12:16] <Saviq> tsdgeos, which, granted, might not be the best thing to do
[12:16] <tsdgeos> Saviq: RGV is not doing that, is it?
[12:16] <tsdgeos> maybe someone below is doing that
[12:16] <Saviq> tsdgeos, no, it's just telling:
[12:17] <Saviq> tsdgeos, ok, I've space for so many columns, and each of them is so wide
[12:17] <tsdgeos> but if you think in RGV terms what karni says makes sense, actually if you look at the test you see it's wrong
[12:17] <karni> Saviq: CardFilterGrid also has "Card" as immediate delegate. Maybe that is why I was confused.
[12:17] <Saviq> karni, yeah, it shouldn't have
[12:17] <karni> ok, now I understand
[12:17] <Saviq> tsdgeos, so it tells the delegate to *be* that size, and center within itself
[12:18] <Saviq> tsdgeos, karni, anyway, I don't think I'm needed here, if you guys understood it and say that's incorrect, I'm fine with that
[12:18] <tsdgeos> yes and no :D
[12:18] <Saviq> trying to be the devil's advocate here
[12:18] <tsdgeos> i think there's something wrong at both levels
[12:18] <tsdgeos> and that one wrong fixes the other
[12:19]  * karni tries something on new-scopes branch
[12:19] <Saviq> karni, tsdgeos the "minimum margin is half of the spacing" part is an assertion
[12:19] <tsdgeos> yes
[12:19] <karni> yes, I did take that into consideration
[12:19] <karni> 2 margins (left+right) = 1 minimum spacing
[12:19] <Saviq> and the calculation takes it into account
[12:19] <tsdgeos> not really
[12:19] <karni> wait.. *thinks*
[12:19] <tsdgeos> i mea
[12:19] <tsdgeos> it does
[12:19] <Saviq> but right
[12:19] <tsdgeos> that's not the issue
[12:19] <karni> if we center the children
[12:19] <tsdgeos> the issue is that it also takes into account an *extra* column
[12:20] <tsdgeos> on the right
[12:20] <karni> then last column could also have "spacing"
[12:20] <Saviq> yeah now I see what you mean
[12:20] <karni> Now that I know children are centered in the delegates, there's a slighty different light to the matter.
[12:20] <tsdgeos> but
[12:20] <Saviq> the "last" spacing
[12:20] <karni> still, if *one* margin is spacing/2
[12:21] <tsdgeos> it is true that make tryResponsiveGridView
[12:21] <karni> then both add up to *spacing*
[12:21] <tsdgeos> makes it look centered
[12:21] <Saviq> is the one that is "sacrificed" for left and rigth margin
[12:21] <tsdgeos> while make tryFilterGrid
[12:21] <tsdgeos> is not
[12:21] <karni> +1
[12:21] <tsdgeos> so someone is doing it wrong somewhere :d
[12:21] <karni> Looking at the code I assumed there was no layer between the delegate and the future (Card) delegate. No item we could center in.
[12:21] <karni> That is why tryFilterGrid was right aligned
[12:22] <karni> If we allow an Item above the delegate body, we can center the child.
[12:22] <Saviq> karni, we need to, as the positioners won't do it for use
[12:22] <Saviq> -
[12:22] <Saviq> -e
[12:22] <karni> So, tryFilterGrid would also look different, it's just the test is implemented in this way.
[12:22] <karni> Right
[12:22] <Saviq> karni, tsdgeos, ok I agree the right-most spacing in that calculation is "sacrificed" for left/right margin
[12:23] <Saviq> so no need for the subtraction
[12:23] <karni> Saviq: Now I don't :| Because if that was the case (which I initially thought) then if delegates are center aligned (in the width including the spacing), where would the last column *align*?
[12:24] <karni> (and I was the one suggesting it was wrong)
[12:24] <Saviq> karni, the whole thing is shifted from the right
[12:24] <Saviq> karni, so it still centers within itself
[12:24] <karni> ok
[12:24] <Saviq> karni, but the whole thing is pushed from the left by margin/2
[12:24] <Saviq> so on the right there's still margin/2 space
[12:25]  * karni admits he needs a moment to think about it
[12:25] <karni> I was assuming spacing was always to the right, that's why we 1) neede margins 2) needed not spacing for the last column
[12:26] <karni> If we center align delegate bodies, left margin + bit of spacing (that'd appear on left and right of center-aligned left most delegate) would be more than right margin of the grid view
[12:27] <Saviq> karni, spacing is actually "inside" the delegate in our case
[12:27] <karni> correct
[12:27] <Saviq> so it's centered within that
[12:27] <Saviq> it's only used to calculate how big the delegate is meant to be
[12:28] <Saviq> so every delegate is minimumWidth + spacing wide
[12:28] <karni> return Math.max(1, Math.floor((parent.width - spacing) / (delegateWidth + spacing))); (not -spacing/2) would be correct formula now, knowing delegates have center aligned bodies.
[12:28] <karni> exactly
[12:28] <karni> And because of that, I take back we should not subtract anything from parent before division. We should, the width of both margins.
[12:29]  * karni makes a new picture
[12:34] <karni> Saviq: tsdgeos: Sent updated picture, considering center-aligned body of the delegates
[12:35] <karni> Maybe one of you could point out what I'm not getting right in the new situation.
[12:35] <karni> Margins are specifically free space on left and right of the layout, different from the "free space" that may show up on left/right of a delegate because of it's center-alignment.
[12:36] <Saviq> karni, right, and in effect all spaces are equal A
[12:37] <karni> Saviq: and there's n+1 of them
[12:37] <karni> thus (parent.width - spacing) / (delegateWidth + spacing)
[12:38] <tsdgeos> ok
[12:39] <Saviq> karni, yes, but that's why the /2 I think, in your case all spaces are always equal, where the left/right margin was meant to be able to be /2
[12:39] <tsdgeos> but that assumes that the delegate will center itself
[12:39] <Saviq> tsdgeos, RGV does assume that
[12:39] <tsdgeos> if it doesn't will look bad
[12:39] <tsdgeos> but ok
[12:39] <karni> tsdgeos: yes, and it turns out we should assume that.
[12:40] <Saviq> tsdgeos, karni, I think that's because we wanted to allow smaller margins than spacing
[12:40] <karni> Saviq: You mean the comment was meant to be "the sum of left and right margin equals spacing/2 at minimum"?
[12:40] <Saviq> or well, Kaleo did
[12:41] <karni> it's so confusing the code says "margin" and in fact means "left+right margin"
[12:41] <Saviq> karni, no, the _visual_ left/right margin is meant to be A/2 at minimum
[12:41] <karni> right
[12:41] <karni> oh
[12:41] <Saviq> karni, I don't think it does
[12:41] <karni> ...
[12:41] <karni> _visual_
[12:41] <Saviq> karni, so in your image, if you take the extreme A/2 out
[12:42] <Saviq> that will result in visually A/2 left and right, and A between items
[12:42] <Saviq> karni, but your formula wouldn't allow it
[12:44] <Saviq> karni, if you go tryResponsiveGridView, maxCol 1000, minSpac 16
[12:44] <Saviq> karni, you can see we're at 8px on left/right, but 16 between items
[12:44] <karni> 8px to the left of grid item, 16px between delegate bodies, yes
[12:45] <Saviq> karni, that's actually when you drop the -spacing/2
[12:45] <karni> yes
[12:45] <Saviq> karni, when it's there, you get huge margins
[12:45] <karni> so, parent.width / (delegateWidth + spacing), is that right?
[12:45] <Saviq> karni, that sounds correct to me, yes
[13:00] <Saviq> karni, just saw your crash in the vj with filter integration, it looks like you've looped the models somehow
[13:01] <Saviq> karni, as it's calling roleNames() on itself until it decides it's enouh
[13:01] <Saviq> +g
[13:02] <Saviq> karni, yup:     property alias model: verticalJournal.model
[13:02] <Saviq>         model: LimitProxyModel {
[13:02] <Saviq>             model: root.model
[13:03] <Saviq> karni, which means the LimitProxyModel uses itself as the backing model
[13:03] <karni> :O
[13:03] <karni> tsdgeos: you where right... I did loop them
[13:05] <Saviq> truth be told I'm not sure we want the LimitFilterModel at all any more...
[13:05] <Saviq> karni, tsdgeos, as we talked, now that we have delegate ranges, we can just clip the views and let them just not draw the delegates outside of the views
[13:06] <Saviq> sure, I really doubt the overhead of drawing one more row (and would we, actually?) is worth the whole Filter dance
[13:07] <Saviq> -sure
[13:07] <karni> I dont think I'm familiar with delegate ranges, but I do know VerticalJournal has no concept of row so.. I got stuck there a bit.
[13:07] <Saviq> karni, yeah, exactly
[13:08] <Saviq> karni, QML *Views only draw the delegates that are within their geometry
[13:08] <Saviq> karni, so, say your GridView is fullscreen, and you can only see 3 rows, 2 items each
[13:09] <karni> neat
[13:09] <Saviq> karni, the GridView will make sure to only instantiate/draw the delegates you have on screen, not the whole model
[13:10] <Saviq> karni, in the dash our problem is that we make the *Views as high as their content is, so that the overall ListViewWithPageHeader behaves correctly
[13:10] <Saviq> karni, so when you expand a category, it expands to its full height, and draws all of them
[13:10] <Saviq> karni, so tsdgeos introduced two new props: delegateCreationBegin and *End
[13:10] <karni> ahaa
[13:11] <karni> okay :D
[13:11] <Saviq> karni, those were unfortunately rejected upstream, but the reason was "because we want to re-do it somewhen in the future completely, and don't touch the crap, 'cause it stinks"
[13:11] <Saviq> karni, with no timeframe
[13:11] <Saviq> karni, so we patched the *Views to include the two above
[13:12] <Saviq> karni, which let us tell the *Views that instead of considering your full geometry, only draw the delegates between *Begin and *End
[13:13] <Saviq> karni, which results in only the delegates which you can see being drawn, even though the *View itself is full-height
[13:14] <Saviq> karni, so yeah, I'm basically starting to think we should drop the *Filter* parts, and just clip the views / change their geometry, so that they take care of the delegates themselves
[13:15] <Saviq> karni, especially with VJournal, where there are no rows, as you said yourself
[13:15] <karni> Now I get it :)
[13:16] <karni> Saviq: thank you for the explanation
[13:16] <karni> Saviq: so delegateCreationBegin/End are used for clipping the rest?
[13:16] <Saviq> karni, so yeah, don't do filtering for VJ
[13:16] <mzanetti> Saviq: hey, so we still have the issue that the phone's rendering performance drops drastically when we have more than ~5 apps open.
[13:16] <mzanetti> which turns out to be an issue for showcasing the right edge
[13:17] <Saviq> karni, well, in that case it's actually not even the delegate*Begin/End, but just the view geometry
[13:17] <mzanetti> cause first thing you do with that branch is to check how it looks with 10 apps in it
[13:17] <Saviq> mzanetti, file a new bug against unity8 and mir please
[13:18] <mzanetti> ok
[13:18] <Saviq> mzanetti, and unity-mir, too, in case it's something there
[13:18] <Saviq> karni, what's more, as you probably saw in the spec
[13:18] <karni> Saviq: clip at 35gu height
[13:18] <Saviq> karni, exactly
[13:18] <Saviq> karni, so just do that in CardVJ
[13:18] <mzanetti> Saviq: given that everything gets slow, I expect it to be in mir's rendering code. but yeah, I'll put all related stuff to it
[13:19] <Saviq> karni, height: filtered ? min(35GU, fullHeight) : fullHeight
[13:19] <Saviq> karni, pseudo-code of course
[13:19] <karni> Saviq: ack, thank you :)
[13:27] <mzanetti> Saviq: https://bugs.launchpad.net/unity8/+bug/1273224
[13:27] <Saviq> mzanetti, thanks
[13:31] <Saviq> mzanetti, confirmed
[13:31] <mzanetti> Saviq: nice
[13:32] <mzanetti> Saviq: given that this issue exists ever since we switched to Mir and noone cared about it, I guess we should raise this bug with kgunn
[13:32] <Saviq> mzanetti, yup
[13:32] <mzanetti> ok. I will do so
[13:40] <om26er> Saviq, mzanetti btw bug 1227739‎ is probably related
[13:49] <mzanetti> om26er: interesting, might be related indeed
[13:50] <Saviq> om26er, about QT_LOAD_TESTABILITY, did you use --global for set-env?
[13:51] <om26er> Saviq, yes I did, I tried with and without it
[13:51] <om26er> even I just replied to your comment there
[13:52] <om26er> I did:
[13:52] <om26er> initctl set-env --global QT_LOAD_TESTABILITY=1
[13:53] <Saviq> om26er, truth be told, did it *ever* work like that for apps?
[13:53] <Saviq> om26er, we have a bit of code in unity8's main()
[13:54] <Saviq> om26er, that loads testability based on the env var, but that would suggests it's a unity8-specific thing at the moment
[13:54] <om26er_> Saviq, network failed me. did you read my message ?
 om26er, truth be told, did it *ever* work like that for apps?
[13:55] <Saviq>  om26er, we have a bit of code in unity8's main()
 om26er, that loads testability based on the env var, but that would suggests it's a unity8-specific thing at the moment
[13:55] <mhr3> Saviq, how much effort is it to hook up tapping in new-scopes?
[13:55] <om26er_> Saviq, Yes, it worked for me a couple of weeks ago
[13:55] <mhr3> Saviq, cuold use it so i can test the previewing and stuff
[13:55] <om26er_> Saviq, I had a working script
[13:56] <Saviq> om26er_, either way it's not a unity8 issue
[13:56] <Saviq> om26er_, not sure where it happened for apps, then
[13:56] <Saviq> om26er_, hopefully thomi/veebers will know
[13:56] <Saviq> mhr3, let me see
[13:57] <om26er_> Saviq, right, QT_LOAD_TESTABILITY is that a qt flag or does it live inside autopilot ?
[13:57] <Saviq> om26er_, it needs to be interpreted by Qt
[13:58] <mhr3> seems like card itself is just missing onClicked... plus some uncommenting then
[13:59] <Saviq> mhr3, http://paste.ubuntu.com/6826324/ should get you going
[14:00] <mhr3> Saviq, mind just pushing that to new-scopes?
[14:00] <ricmm> Saviq: sup
[14:00] <ricmm> Saviq: Londres is good as usual
[14:00] <Saviq> mhr3, otp now
[14:00] <ricmm> but im tired of not being home
[14:00] <mhr3> Saviq, i take that as "feel free to push yourself" :)
[14:00] <Saviq> mhr3, as long as you fix it first ;)
[14:00] <Saviq> mhr3, or verify it works, at least
[14:03] <greyback> ricmm: I know that feeling :)
[14:30] <mzanetti> all: kgunn, Saviq, tsdgeos and me will be a bit late for the standup. Cimi, can you take over with guiding the standup?
[14:31] <Cimi> mzanetti, sure
[14:37] <Saviq_> kgunn, going to standup
[14:39] <kgunn> Saviq: ack, i'm in ...my network freaked out
[14:40] <Saviq> kgunn, your pulseaudio freaks out again, too :/
[14:42] <bregma> didrocks, were the compiz/nux/unity7 daily PPA builds really supposed to be turned off again?  The latest rare and precious CI build failed because of weeks-old binaries.
[14:43] <didrocks> bregma: I asked to turn it on on Friday, not sure if it was done. let's see if sil2100 can have a look ^
[14:44] <sil2100> didrocks, bregma: those don't seem to be re-enabled from what I see, let me reenable
[14:44] <bregma> is there any reason why the dailes need to be turned off?  nothing in Touch depends on them, they're leaf nodes
[14:46] <sil2100> bregma: we had all dailies disabled and doing only manual stack runs because of some crucial landings - but we can reenable now I guess
[14:46] <sil2100> didrocks: can I reenable?
[14:46] <didrocks> sil2100: sure, I asked on Friday already :)
[14:46] <didrocks> sil2100: thanks a lot!
[14:48] <mzanetti> elopio: a, forgot to mention: at some point we did have those coverage results in jenkins, but some jenkins upgrade broke the collection of artifacts and we didn't get it back since
[14:48] <sil2100> didrocks: oh, one question while we're at it - the unity stack has like unity-scope-mediascanner in it, and since it's basically a unity8-specific scope, it's not building for powerpc
[14:48] <mzanetti> elopio: but the coverage.xml file generated by runtests.sh is compatible with jenkins
[14:48] <sil2100> didrocks: so the unity stack keeps waiting for it in the build phase, while it depwaits
[14:48] <sil2100> didrocks: can we disable this one scope for powerpc in cu2d in the unity stack build?
[14:48] <sil2100> didrocks: or it's per-stack only?
[14:49] <didrocks> sil2100: it can be per project, but it's per run
[14:49] <elopio> mzanetti: good to know, I'll take that into account.
[14:49] <didrocks> so you will get the same issue in the next 8 hours
[14:49] <mzanetti> kgunn: may I ask you to create some visibility/priority on this one? https://bugs.launchpad.net/unity8/+bug/1273224
[14:49] <sil2100> didrocks: ah, cu2d-skip - but a global skip, like for unity8 stack?
[14:49] <sil2100> didrocks: since you made unity8 ignore powerpc right?
[14:49] <didrocks> sil2100: yeah, it's support per stack or per projects IIRC
[14:49] <sil2100> (for ever)
[14:49] <didrocks> no
[14:49] <didrocks> it doesn't ignore forever
[14:50] <didrocks> it ignores because it was never published in ubuntu
[14:50] <didrocks> on powerpc
[14:50] <sil2100> ah, ok
[14:50] <sil2100> Crap
[14:50] <sil2100> Thanks ;)
[14:50] <kgunn> mzanetti: ack
[14:50] <didrocks> sil2100: yw! ;)
[14:52] <kgunn> tedg: were you involved in the original "multiple apps open = slow" investigation ?
[14:55] <dednick> mzanetti: neither the plugins or qml folder seems to have the qml files included with the Unity/Indicators plugin. Any idea what needs doing?
[14:55] <mzanetti> dednick: what?
[14:55] <tedg> kgunn, Sorry, xchat crashed.
[14:55] <tedg> kgunn, I don't think I was in that one.
[14:56] <mzanetti> dednick: ah... you're missing qml files in the project tree?
[14:56] <dednick> mzanetti: you did the CMake thing for qtcreator right?
[14:56] <dednick> mzanetti: yah
[14:56] <mzanetti> dednick: where are they?
[14:57] <dednick> mzanetti: plugins/Unity/Indicators/qml
[14:57] <mterry> Are unity8 CI runs just borked?   I have a simple branch that doesn't even touch anything tested and they are failing
[14:57] <mzanetti> dednick: I see. I'd suggest adding them to the Indicators target in there
[14:57] <dednick> mzanetti: maybe they should be moved to qml/plugins/Unity/Indicators ?
[14:57] <mzanetti> Saviq: ^ ?
[14:58] <fginther> tsdgeos, I have some info on the unity8 otto test failure
[14:58] <tsdgeos> fginther: cool
[14:58] <mzanetti> dednick: so yeah, either that or add them to the target in plugins/Unity/Indicators
[14:58] <fginther> tsdgeos, the problem appears to be dependency related. If I remove http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ as an apt archive, the tests pass
[14:59] <Saviq> mterry, yes, tsdgeos and fginther are on it ↑
[14:59] <dednick> mzanetti: ok, thanks
[14:59] <mzanetti> dednick: I for one would keep them where they are and add them to the target in there.
[14:59] <mterry> Saviq, awesome
[14:59] <fginther> tsdgeos, example: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/2297/
[15:00] <tsdgeos> woot, i think i just found a bug in lvpwh
[15:00] <tsdgeos> fginther: interesting, i was thinking that was the case, but when i ran on the phone with naartjie enabled it still worked, but i'll try again on my desktop
[15:01] <Saviq> mzanetti, not sure what question am I supposed to answer?
[15:01] <tsdgeos> fginther: have you been able to reproduce the problem locally?
[15:01] <mzanetti> Saviq: would you keep indicators qml files where they are and add them to the target in there, or would you move them to qml/ so they show up in the project tree in there?
[15:02] <fginther> tsdgeos, I'm not in a position to retest locally at the moment, but I have another example:
[15:02] <Saviq> mzanetti, dednick, I think we'll be splitting up other .qmls a bit into plugins, too, so yeah, keep them there
[15:02] <mzanetti> ack
[15:02] <fginther> http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-debug-fjg/15 also passed when I removed the naartjie source, but failed when it was there (see build 14)
[15:03] <fginther> tsdgeos, this appear to be desktop only perhaps?
[15:03] <tsdgeos> fginther: might be
[15:03] <tsdgeos> fginther: i'll try polluting my destkop with naartjie and see what happens
[15:04] <fginther> tsdgeos, there are only a few packages there, you should be able to track them and revert back when you're done
[15:09] <dednick> mzanetti: hm, as far as i can tell, they are added to a target. Although it uses a macro to do it...
[15:18] <mzanetti> dednick: still not working? need help?
[15:18] <dednick> mzanetti: please
[15:19] <mzanetti> ack.
[15:20] <dednick> mzanetti: thanks.
[15:20] <dednick> mzanetti: what actually determines which files are added to project in creator?
[15:21] <mzanetti> dednick: with cmake, I think it's listing everything that's given as source of a target
[15:21] <dednick> mzanetti: the plugins/Unity/Indicators/qml folder is there with the CMakeList.txt file, but there's no other files listse
[15:22] <dednick> mzanetti: hmm. let me try adding files on another target to confirm
[15:24] <mzanetti> dednick: https://code.launchpad.net/~mzanetti/unity8/indicators-qml-to-cmake/+merge/203351
[15:26] <mzanetti> dednick: just pushed again to align it with the rest of the file
[15:28] <dednick> hm. wonder why it doesnt work with the export_qmlfiles macro
[15:28] <dednick> mzanetti: ^ ?
[15:28]  * mzanetti reads
[15:29] <mzanetti> dednick: I don't think it does custom_targets, only real targets
[15:29] <mzanetti> dednick: as custom targets mostly do some command line execution which cmake and qtcreator don't have any clue about
[15:30] <dednick> i c
[15:30] <tsdgeos> fginther: awesome, it fails :-)
[15:30] <mzanetti> dednick: but yeah, we try to could create some no-op but real target inside the macro I guess
[15:30] <tsdgeos> which means NOT_OUR_BUG
[15:30] <tsdgeos> btu still have to fix it :D
[15:31] <mzanetti> ... we could try...
[15:31] <dednick> mzanetti: yup, looking at it now
[15:31] <mzanetti> cheers
[15:33] <fginther> tsdgeos, whew! glad that helped
[15:36] <dednick> mzanetti: hm... there doesnt seem to be a target for the root/qml qml files other than the install target. so...
[15:52]  * tsdgeos does evil eyes to MacSlow and mzanetti
[15:52] <MacSlow> tsdgeos, ?
[15:52] <tsdgeos> your last unity-notifications breaks your notification unit tests in unity8
[15:53] <MacSlow> tsdgeos, outch
[15:53] <tsdgeos> yeah, has been making our CI fail the whole last week and i was blaming CI machines
[15:53] <tsdgeos> just did not understand they used some packages that are not in distro
[15:55] <MacSlow> tsdgeos, so it's got to be r192 of lp:unity-notifications
[15:55] <tsdgeos> 193
[15:56] <mzanetti> oops
[15:56] <mzanetti> tsdgeos: hmmm... does that mean we should run unity8 tests when merging to unity-notifications?
[15:56] <tsdgeos> mzanetti: that means unity-notifications needs better tests :D
[15:57] <MacSlow> mzanetti, tsdgeos: hm
[15:57] <MacSlow> tsdgeos, do you have a link to one such CI-failure handy?
[15:58] <tsdgeos> mzanetti: please build unity-notifications, install it, and then run PYTHONPATH=../tests/autopilot autopilot run unity8.shell.tests.test_notifications.InteractiveNotificationBase.test_sd_incoming_call
[15:59] <MacSlow> tsdgeos, I'll try that on the emulator too
[15:59] <tsdgeos> MacSlow: this is blocking all our CI, do it on your computer, will be faster than messing with the emulator
[16:00] <MacSlow> tsdgeos, doing that too
[16:06] <tsdgeos> mzanetti: MacSlow: https://code.launchpad.net/~aacid/unity-notifications/qcompare/+merge/203362
[16:07] <MacSlow> tsdgeos, mzanetti: ok, I'm onit
[16:07] <mzanetti> cheers
[16:07] <mzanetti> tsdgeos: what exactly caused the fail in here?
[16:07] <tsdgeos> mzanetti: that doesn't fix anything
[16:07] <mzanetti> ah ok
[16:07] <tsdgeos> just makes stuff better
[16:08] <mzanetti> yeah. I agree with that
[16:08] <tsdgeos> MacSlow:
[16:08] <MacSlow> tsdgeos, so it's not fixing the CI-failure you mentioned earlier?!
[16:08] <tsdgeos>          if (!inserted) {
[16:08] <tsdgeos> -            insertToVisible(n, 0);
[16:08] <tsdgeos> +            insertToVisible(n, insertionPoint(n));
[16:08] <tsdgeos>          }
[16:08] <tsdgeos> fixes unittest in unity8 for me
[16:08] <MacSlow> ok
[16:08] <tsdgeos> but breaks unity-notification unittests
[16:08] <tsdgeos> so you have to make them agree :D
[16:09] <MacSlow> tsdgeos, I'll make sure to get this sorted before tomorrow
[16:10] <tsdgeos> tx
[16:19] <om26er> xnox, xnox, is there a way to set a global variable in the environment so that every app that starts with initctl appends that parameter ? talking a parameter thats not a keyword arg
[16:20] <xnox> om26er: can you please tell me what you are trying to do? and is it generic, or upstart-app-launch specific?
[16:22] <om26er> xnox, not sure about the details on what 'initctl start' uses. there is a parameter QT_LOAD_TESTABILITY=1 which if set in the environment starts all the apps with the testability driver load, due to some reason its broken. So there is an alternative parameter '-testability' which is working, So I would like to start my apps with that
[16:23] <xnox> om26er: talk to qa / ci / tedg  about it. check why your environment doesn't have that variable.
[16:24] <xnox> om26er: cause environment variable is supported better, but it also depend on your code.
[16:24] <xnox> om26er: do you have your log, where testability is / isn't loaded?
[16:28] <tedg> om26er, It might be when it gets set, for best results I'd say make a job that is "start on starting dbus" that sets it.
[16:29] <om26er> xnox, where are the upstart logs when an app is started with initctl ?
[16:30] <om26er> tedg, will '-testability' work as well ? I though initctl supported arguments of the form key=arg ?
[16:30] <tedg> om26er, Nope, it doesn't.
[16:31] <tedg> om26er, The app will put logs in ~/.cache/upstart/application*
[16:33] <om26er> xnox, logs when started with upstart http://paste.ubuntu.com/6827040/
[16:34] <om26er> xnox, and with -testability (without upstart) http://paste.ubuntu.com/6826992/
[16:34] <om26er> note the line: Testability driver loaded. Wire protocol version is "1.4".
[16:38] <tedg> om26er, How are you setting the env var?
[16:38] <tedg> initctl set-env --global QT_LOAD_TESTABILITY=1 ?
[16:38] <om26er> tedg, inictl set-env -g QT_LOAD_TESTABILITY=1
[16:38] <om26er> or that
[16:39] <MacSlow> tsdgeos, btw... your fix-suggestion for unity-notifications does cause 2 of the current unit-tests of unity-notifications to fail
[16:39] <tsdgeos> MacSlow: yes, is exactly what i said
[16:39] <tsdgeos> [17:08:31] <tsdgeos> fixes unittest in unity8 for me
[16:39] <tsdgeos> [17:08:40] <MacSlow> ok
[16:39] <tsdgeos> [17:08:40] <tsdgeos> but breaks unity-notification unittests
[16:39] <tsdgeos> [17:08:47] <tsdgeos> so you have to make them agree :D
[16:40] <MacSlow> tsdgeos, hm... guess xchat's scrollback doesn't like me then :)
[16:40] <tedg> om26er, initctl get-env QT_LOAD_TESTABILITY ?
[16:40] <MacSlow> tsdgeos, with current lp:unity8 and lp:unity-notifications only notification-autopilot-tests fail for you?
[16:40] <tsdgeos> no
[16:41] <tsdgeos> well
[16:41] <MacSlow> tsdgeos, ah ok... atm 48 out of 65 fail for me here
[16:41] <tsdgeos> what does "notification-autopilot-tests" mean?
[16:41] <tsdgeos> ah yes, only the one i told you fails
[16:41] <tsdgeos> unity8.shell.tests.test_notifications.InteractiveNotificationBase.test_sd_incoming_call
[16:41] <tsdgeos> MacSlow: how are you running the tests?
[16:41] <MacSlow> tsdgeos, *sigh*
[16:42] <om26er> tedg, that does not work as well. So I just concluded it to be a bug in autopilot somewhere. Apps that are started with qmlscene are loading the testability driver, but the ones that have a c++ binary are showing the issue
[16:42]  * om26er reports a bug for autopilot-qt
[16:43] <MacSlow> tsdgeos, doing the usual compile (and installing unity-notifications via the build .deb), make install in builddir and then starting autopilot
[16:43] <tsdgeos> MacSlow: read the CODING file
[16:43] <tsdgeos> make autopilot
[16:44] <tsdgeos> or you need to properly pass PYTHONPATH stuff around
[16:45] <tsdgeos> mzanetti: have a sec?
[16:51] <karni> mhr3: Can you tell me what you meant by "they stop being centered" comment? https://code.launchpad.net/~unity-team/unity8/new-scopes-fix-grid/+merge/202593
[16:51] <karni> mhr3: Do you mean "it makes things look worse", as opposed to the screenshots?
[16:52] <mhr3> karni, yes, the patch de-centered them
[16:52] <karni> mhr3: ack, thanks
[16:52] <mhr3> karni, but in trunk
[16:54] <om26er> mzanetti, hello
[16:54] <karni> greyback: Hiya. I believe you where the author, allow me to ask - where did the "- spacing/2" come from in qml/Components/ResponsiveFilterGrid.qml columnsForSpacing function?
[16:54] <karni> return Math.max(1, Math.floor((parent.width - spacing/2) / (delegateWidth + spacing)));
[16:54] <greyback> karni: that was a while ago, let me try refresh my memory
[16:55] <karni> greyback: thank you, I'd appreciate
[16:58] <karni> greyback: Two people other than me got convinced it should probably be (parent/(delegateWidth + spacing)) (i.e. nothing should be subtracted from parent width, because that far right spacing would be spread to both margins)
[16:59] <karni> greyback: http://paste.ubuntu.com/6827155/ ~3:50 ago on this channel
[17:00] <mhr3> karni, your formula was correct if the margin assumption was... if margins are 0 it isn't
[17:01] <karni> mhr3: by margins you mean the visual space between a delegate and screen edge, or from the delegate body to delegate edge? (because we assume the deletate contents are center aligned)
[17:02] <greyback> karni: yeah I can't think of a good reason why I subtract the spacing/2
[17:02] <mhr3> oh wait, that space is allocated to the columns anyway, so nevermind
[17:03] <karni> greyback: ack
[17:14] <karni> mhr3: quick question, how did you check that? in a test, or you built it and tried on a device/in a simulator?
[17:14] <karni> the fact that it didn't work with trunk
[17:14] <karni> I'm not assuming it does, I'm just asking to ensure best work flow on my end
[17:17] <mhr3> karni, i merged that one commit you did into trunk
[17:17] <karni> right, and then? :)
[17:33] <karni> mhr3: If you're still around, I was wondering more about the next step :) How you verified that merge to trunk broke it.
[17:50] <mhr3> karni, i just run the scope tool
[17:50] <karni> mhr3: ack
[17:51] <mhr3> in trunk it's talking to old scopes, and not using cards, and was not centered
[17:51] <karni> gotcha, thanks buddy
[18:03] <Cimi> mterry, it still failed, though https://code.launchpad.net/~unity-team/unity8/unity8.test_nested_mir/+merge/203088
[18:04] <Cimi> Saviq, still around?
[18:05] <mterry> Cimi, I think CI tests are having problems right now
[18:14] <Saviq> Cimi, mterry yes, we're getting closer, though
[18:27] <karni> Saviq: How is it possible that Cards delegates (scope-onlinemusic in new-scopes unity-scope-tool) are left-aligned, as it seems, while tiles in unity8 trunk unity-scope-tool are centered? When I manage to center align the Card delegates, the trunk tiles get moved to the right. I feel like someone cheated, stuff is actually shifted/centered in tile delegates, but I can't find it. I'm puzzled.
[18:27] <karni> Either trunk has centered tiles, or new-scopes has centered Cards. Can't make 'em both work.
[18:29] <karni> Saviq: (if you're around) lp:~unity-team/unity8/unity8-fix-grid - rev 653 correctly fixes column count. rev 654 breaks tile alignment (they're shifted to right), but the very same code centers Cards in new-scopes :/
[18:42] <Saviq> karni, isn't this because Cards do not center themselves while old-scopes renderers do?
[18:43] <karni> Saviq: I think so, as you wrote your message - I started to align the Card
[18:43] <karni> yeah, giving this a try
[18:43] <Saviq> karni, align the Card how? within an enclosing Item?
[18:43] <karni> Saviq: yes. would that be fine?
[18:43] <karni> Saviq: delegate: Card -- eek
[18:43] <Saviq> karni, yes
[18:43] <karni> :)
[18:44] <Saviq> karni, problem is there's a loop there
[18:44] <Saviq> karni, delegateHeight/Width: are based on first delegate size
[18:44] <karni> Saviq: well.. first try failed miserably ;) all card positions went haywire. lemme work that.
[18:45] <Saviq> karni, which is a shortcut that we need to get rid of (hence the FIXME in CardFilterGrid)
[18:45] <karni> ack
[18:45] <karni> ah yes, I see it
[18:45] <Saviq> karni, so yeah, we've a chicken'n'egg problem
[18:45] <karni> not good, not good :[
[18:45] <Saviq> karni, the plan for that is to create an invisible Card with dummy data for each category
[18:46] <karni> I really need to get this fixed to get going.
[18:46] <Saviq> karni, to find out its largest possible size
[18:46] <karni> I see..
[18:46] <Saviq> karni, and use that for delegateWidth/Height in the different layouts
[18:46] <karni> So basically I could fix column count, but card spacing/alignment is not that easy.
[18:46]  * karni nods
[18:46] <Saviq> karni, I'll work on that tomorrow morning
[18:47] <karni> Saviq: Appreciated, Michał -- you know where's my branch if you'd like to test it. That's based on unity8 trunk.
[18:47] <karni> I was trying to make it right in trunk, but second commit in that branch works in new-scopes only.
[18:49] <karni> Aha, so I should actually revert that last change, if the problem is in *Card* alignment.
[18:51] <Saviq> karni, yeah, I'd say it is
[18:51]  * karni nod
[18:57]  * greyback eod
[18:58] <karni> If I want to "cancel" my merge proposal, is Deleting it the right thing to do? I left a comment pointing to a different branch and left further explanation, which I assume will be sent to interested parties? https://code.launchpad.net/~unity-team/unity8/new-scopes-fix-grid/+merge/202593
[19:33] <tedg> karni, You can set it to WIP or Rejected as well.
[19:34] <tedg> karni, I'd say "make it informative" for the next person that sees it. :-)
[19:34] <karni> tedg: I've it to Rejected, only later I noticed. That'd be my first time I did it heheh
[19:34] <karni> Right :) Thanks
[20:02] <Saviq> karni, one for you: https://code.launchpad.net/~saviq/unity8/fix-card-header-height/+merge/203411
[20:02]  * karni looks
[20:03] <Saviq> karni, empty labels were taken into account for height calculations
[20:04] <karni> Saviq: slick /me awaits diff :)
[20:04] <karni> Saviq: Since you're here :) https://code.launchpad.net/~unity-team/unity8/unity8-fix-grid/+merge/203399
[20:04] <Saviq> karni, just pushed a trunk merge, so it'll still be there
[20:04] <Saviq> karni, naah, not _really_ here ;)
[20:04] <karni> heheheheh ok
[20:04] <karni> Saviq: what did you mean by "pushed a trunk merge"?
[20:05] <Saviq> karni, my branch did not have latest trunk in (in fact it was a week old or so)
[20:05] <karni> oh, gotcha
[20:05] <karni> thanks, Saviq :)
[20:06] <Saviq> this helps a bit in the layouts as cards are actually their own size as opposed that + two lines of invisible text...
[20:07] <karni> Saviq: It's good to _not_ have invisible views in there hehe
[20:07] <Saviq> karni, indeed
[20:07] <karni> Saviq: fun fact:
[20:08] <karni> Saviq: The fix for column spacing works for new-scopes *and* trunk, if there's 2 columns. If there's 3, margins are too wide (wtf?) and that's why stuff is shifted.
[20:08] <Saviq> karni, yeah, we'll have to look at it properly
[20:09] <karni> I don't know how that relates to column count, the math is there, and makes sense. anyway. I don't want to hold you here :)
[20:09] <karni> I don't plan to leave anytime soon (modulo food)
[20:09] <karni> Saviq: yep
[21:33] <Saviq> mterry, fyi, adding the repo from http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ allowed Albert to reproduce the failures in otto, and there's a fix for lp:unity-notifications in the works
[21:37] <Saviq> mterry, fyi, adding the repo from http://naartjie.ubuntu-ci/archive/head.unity8/trusty/ allowed Albert to reproduce the failures in otto, and there's a fix for lp:unity-notifications in the works
[21:37] <mterry> Saviq, ah interesting.  OK, thanks!
[21:38] <Saviq> mterry, that repo contains all packages built for the unity8 stack (so unity8, unity-notifications etc.) during -autolanding jobs
[21:39] <mterry> Saviq, so like trusty-proposed-proposed?  :)
[22:07] <Saviq> mterry, well, it's meant to allow us coordinate merges within the stacks without release
[22:08] <Saviq> mterry, as the stacks are later released together (or at least were originally)
[22:14] <kgunn> mterry: are you looking into the weird "unstable" otto runs ?
[22:14] <kgunn> i was trying to bug someone/anyone in ubuntu-ci-eng
[22:15] <mterry> kgunn, I was curious about them, but mostly I've been having trouble reproducing a certain jenkins test failure in one of my branches that added a new AP test
[22:18] <kgunn> mterry: cool...i'll go back to bothering ci team :)
[22:19] <kgunn> as its holding up cimi's mp
[22:22] <Saviq> kgunn, Albert found the issue today
[22:23] <Saviq> kgunn, it was r192-193 in https://code.launchpad.net/~unity-api-team/unity-notifications/trunk
[22:23] <Saviq> kgunn, fix was already identified, too
[22:24] <kgunn> Saviq: thanks...i'll stop harping on it...assuming there'll be an mp to address it in the morning
[22:24] <kgunn> Saviq: does it really address all 4 here
[22:24] <kgunn> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2304/
[22:26] <Saviq> kgunn, no, but at least two of those are added in that MP
[22:26] <Saviq> https://code.launchpad.net/~unity-team/unity8/unity8.test_nested_mir/+merge/203088
[22:26] <Saviq> so those just need fixing
[22:26] <Saviq> the only persistent failure we got was http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/2315/
[22:29] <veebers> Saviq: I'm eavesdropping here, I see you're having autopilot test failures. When did that start happening?
[22:29] <Saviq> veebers, last week, a merge in lp:unity-notifications caused it - we had problems reproducing 'cause it was never released, but was there in the local head.unity8 repo
[22:30] <Saviq> veebers, issue identified and will be resolved early tomorrow
[22:30] <veebers> Saviq: ah ok, I ask because a new autopilot was released and entered distro a couple of hours ago. I wanted to make sure it wasn't that ;-)
[22:30] <Saviq> veebers, nah
[23:39] <karni> Saviq: this looks so much better, +1. should I top approve? should you ping mzanett'i to land it? I think there's a new landing process involving adding entries to a gdoc. you might want to ask him.