[07:28] <Saviq> tsdgeos, o/
[07:28] <Saviq> tsdgeos, how was it?
[07:28] <tsdgeos> good
[07:28] <tsdgeos> a bit too rainy
[07:29] <tsdgeos> damn central europe and it's crazy weather
[07:29] <Saviq> ;)
[07:29] <tsdgeos> my sneakers are of perfectly brown color now cause of the mud
[07:30] <tsdgeos> but nothing a whashing machine can't fix
[07:30]  * tsdgeos reading emails
[07:48] <tsdgeos> Saviq: karni: there's a bug complaining about seemore/less but it hasn't been merged :S or has it?
[07:48] <Saviq> tsdgeos, no, mhr3 is resurrecting it with the new designed behaviour
[07:49] <mhr3> Saviq, eh, yea.. about that
[07:49] <tsdgeos> ok, so he said last week, i was just surprised we got a bug for something wasn't merged
[07:49] <Saviq> tsdgeos, which one?
[07:49] <mhr3> ...just a sec, in meeting
[07:49] <Saviq> tsdgeos, ah that one
[07:49] <Saviq> tsdgeos, it was in Preview I imagine
[07:49] <tsdgeos> ah
[07:49] <tsdgeos> may be
[08:14] <mhr3> Saviq, tsdgeos, so i have a branch that has the see more button (based on tsdgeos' one) and adds support for the expansion queries, but there are issues with the see more that i wasn't able to fix... clipping in the section headers and on the see more widget itself
[08:15] <mhr3> was hoping you could finish it, cause there's just too much lvwph magic
[08:15] <mhr3> it's all in lp:~unity-team/unity8/grid-see-more
[08:20] <tsdgeos> Saviq: do we have an easy way to reproduce https://bugs.launchpad.net/unity8/+bug/1337408 ?
[08:20] <Saviq> tsdgeos, probably in tryDash, after modifying fake_categories?
[08:20] <tsdgeos> i meant realworld code, but sure, that should do it
[08:20] <tsdgeos> let's see
[08:22] <Saviq> tsdgeos, there's the store button, that's the only category with a single result
[08:22] <Saviq> tsdgeos, or well, you could probably search so that you get one result
[08:22] <Saviq> tsdgeos, and override the category in scopetool then
[08:50] <Saviq> mhr3, btw, karni reported yesterday, not sure he caught you, that if he has a canned query in a preview button, but one with empty searchQuery, it doesn't execute → only after he started typing did the new department etc. get loaded
[08:52] <karni> actually, I didn't type, I just tested with CannedQuery with set department and 1) unset query string 2) query string set to " " -- 1) only updated departments dropdown, not the results
[08:52] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/verticalJournalSingleResultHeightBug/+merge/225937
[08:52] <karni> 2) did update the results (as if it forced refresh), but I had this ugly search box at the top. AND, when I press back I was actually at the top, not in subdepartment
[08:53] <tsdgeos> Saviq: unfortunately we do not really have tests for CardVerticalJournal
[08:54] <Saviq> tsdgeos, I know :|
[08:55] <mhr3> karni, bug?
[08:55] <karni> mhr3: https://bugs.launchpad.net/unity-scopes-api/+bug/1338616
[08:57] <mhr3> karni, didn't you hit this btw? https://bugs.launchpad.net/unity-scopes-shell/+bug/1335761
[08:58] <karni> mhr3: that too, then I pinned the scope, like you suggested.
[08:59] <mhr3> karni, oh does your result take you to a new scope?
[08:59] <mhr3> not the original one?
[08:59] <Saviq> oh my... messages is now a bell button :|
[08:59] <Saviq> s/button/icon/
[08:59] <mhr3> karni, also, you didn't read it :)
[08:59] <karni> mhr3: I'm not sure where it takes me, to be honest. may be my scope, but search rather than subdepartment (even though these work)
[09:00] <karni> mhr3: huh?
[09:00] <mhr3> karni, that bug says that activating a scope query doesn't close the preview
[09:00] <mhr3> doesn't say anything about pinning
[09:00] <karni> mhr3: which bug?
[09:01] <karni> my or yours
[09:01] <karni> *mine
[09:01] <mhr3> mine
[09:02] <karni> mhr3: true. I read the title, so I thought you're referencing "Activating a preview with a scope URI for the current scope doesn't send you back to the *proper results* view, just back to where you were"
[09:03] <karni> mhr3: so if that helps, no - that's not one of the two bugs that I found. It's a different one.
[09:03] <tsdgeos> Saviq: did you ever reproduce https://bugs.launchpad.net/unity8/+bug/1330899 ?
[09:03] <Saviq> tsdgeos, yes
[09:04] <Saviq> tsdgeos, it was enough to just go down to art alone in a grid layout
[09:04] <mhr3> karni, ok, anyway, yep, definitely a bug, will need fixing
[09:04] <tsdgeos> Saviq: so art only in a grid made that happen?
[09:04] <tsdgeos> weird
[09:05] <tsdgeos> let's see if i can reproduce
[09:05] <mhr3> Saviq, could i land u8 today? want to push latest unity-api, so will need to fix u8's ftbfs
[09:06] <Saviq> mhr3, I wanted to land, yes, waiting for silo 4 to clear up
[09:15] <Saviq> tsdgeos, no opinion on the other points in scope-customizations discussion? name was kinda easy to decide on ;)
[09:15] <tsdgeos> Saviq: well i'd personally vote on just pass down all stuff individually
[09:15] <tsdgeos> which is what kind of what my first patch had
[09:15] <tsdgeos> but if you both agree we don't want that
[09:15] <tsdgeos> i guess what we have now is the only other option i can think of
[09:19] <Saviq> tsdgeos, yeah, there's going to be too much passed individually, and would mean that everything in between would need a useless property
[09:19] <tsdgeos> Saviq: or alias, but i see why you don't like it
[09:21] <Saviq> tsdgeos, so what do you think about the default objects to avoid init warnings? I like those more than `foo ? foo.bar : "baz"` TBH
[09:21] <Saviq> especially because suddenly "baz" needs to be hardcoded everywhere
[09:22] <tsdgeos> it's weird (in the sense we don't do it anywhere else)
[09:22] <tsdgeos> but kind of works
[09:23] <Saviq> tsdgeos, yeah, we don't do it 'cause we didn't think of it ;)
[09:23] <Saviq> tsdgeos, I agree we should stick to one approach or the ohter
[09:23] <Saviq> other
[09:24] <tsdgeos> sure sure
[09:24] <Saviq> tsdgeos, so what we say here will have bearing on what we do later
[09:25] <Saviq> one surprising thing for me was that with `property ScopeStyle scopeStyle: null` it still created the ScopeStyle object (I think we saw that before somewhere)
[09:25] <Saviq> with var it doesn't do it
[09:25] <mhr3> oh crap, stupid tags again
[09:26] <Saviq> mhr3, there's a .py script now
[09:26] <Saviq> mhr3, down to a second locally
[09:26] <Saviq> mhr3, 3 minutes remotely
[09:26] <mhr3> how the hell did get infected
[09:26] <tsdgeos> Saviq: yes, that's kind of related to the fact that "`property ScopeStyle scopeStyle: null" fails if ScopeStyle is uncreatable c++ type
[09:26] <Saviq> mhr3, http://people.canonical.com/~msawicz/unity8/strip-u8-tags.py
[09:26] <mhr3> frickin tag virus :P
[09:26] <tsdgeos> simon said the parser is smart enough and should not do it
[09:26] <mhr3> Saviq, yea, thx running it already
[09:26] <tsdgeos> but it's a bug
[09:26] <mhr3> Saviq, nice touch putting it in the checklist ;)
[09:26] <Saviq> mhr3, indeed, the only thing the checklist is useful for ;)
[09:28] <Saviq> tsdgeos, yup, understood - still I would not like to have to use an object of the actual type if I can help it
[09:29] <Saviq> tsdgeos, any idea whether what I did, which does after all require creation of an (small, but still) object is more performance heavy than "if (foo)" everywhere?
[09:29] <Saviq> on the one hand it's only creation time, on the other that's when 99% of the bindings would get evaluated anyway
[09:29] <tsdgeos> it's probably more startup heavy
[09:29] <tsdgeos> which i guess we can take
[09:29] <tsdgeos> over runtime heavy
[09:29] <tsdgeos> in this case
[09:30] <Saviq> tsdgeos, well, not only startup, delegate creation, too :|
[09:30] <tsdgeos> right
[09:30] <Saviq> tsdgeos, since we have this in every card in the dash
[09:30]  * Saviq runs benchmark
[09:30] <tsdgeos> Saviq: does maketryCardBencharmrk say any difference?
[09:31] <Saviq> tsdgeos, just trying out
[09:36] <Saviq> tsdgeos, http://pastebin.ubuntu.com/7764637/
[09:36] <Saviq> :|
[09:37] <mzanetti> vesar: hangout?
[09:37] <tsdgeos> Saviq: just adding the property makes it slow?
[09:37] <tsdgeos> that's weird
[09:37] <tsdgeos> is it reproducible?
[09:37] <Saviq> tsdgeos, slow?
[09:38] <Saviq> tsdgeos, the differences are .05msec
[09:38] <tsdgeos> cardTitleArtSubtitleModel went from 708 to 743
[09:38] <Saviq> tsdgeos, well, not just the property
[09:38] <Saviq> tsdgeos, had to add "if (foo) bar"
[09:38] <tsdgeos> right
[09:38] <Saviq> tsdgeos, http://paste.ubuntu.com/7764642/
[09:39] <Saviq> tsdgeos, tbh on second try it went up for null as well
[09:39]  * Saviq runs under xvfb
[09:40] <tsdgeos> may not be stablest benchmark ever
[09:40] <Saviq> lol, it's faster under xvfb
[09:40] <tsdgeos> you may be on the verge of it not being exact enough
[09:40] <tsdgeos> for stuff like 10 msec
[09:40] <Saviq> but only 128 iterations for some reason
[09:41] <Saviq> tsdgeos, ok, I'd say negligible
[09:42] <Saviq> tsdgeos, difference, that is
[09:42] <tsdgeos> ok
[09:43] <tsdgeos> Saviq: you can't have subtitle without title on a card, right?
[09:43] <Saviq> tsdgeos, even trunk is getting higher at times than either solution
[09:43] <Saviq> tsdgeos, nope
[09:43] <tsdgeos> good
[09:43] <tsdgeos> then i guess it's ok
[09:43] <mhr3> how come you're not computing stddev when running the benchmarks? :)
[09:44] <Saviq> mhr3, pfft
[09:45] <mhr3> it can actually spot changes in cache behaviour surprisingly well
[09:46] <mhr3> not that you should care about that too much :P
[09:46] <Saviq> mhr3, truth is we rely on Qt doing the benchmark
[09:46] <Saviq> mhr3, not doing anything special there
[09:46] <Saviq> greyback, you should switch to in-header gpg sig
[09:46] <greyback> Saviq: why?
[09:46] <Saviq> greyback, people get scared by things like that if they don't know what it's about
[09:47] <Saviq> greyback, I get it displayed as part of the mail body, is all
[09:48] <greyback> Saviq: I'm using pgp default settings, assumed it was sensible
[09:50] <greyback> can't find setting in the UI
[09:50] <Saviq> greyback, somewhere there's a setting for PGP/MIME, trying to find it, too
[09:50] <Saviq> greyback, I think it might be per account
[09:51] <Saviq> greyback, yeah, go to accounts settings → OpenPGP, "Use PGP/MIME by default"
[09:52] <Saviq> tsdgeos, btw, did we not have previews in tryDash at some point?
[09:52] <tsdgeos> we had previews somewhere
[09:52] <tsdgeos> either tryDash or GSV or somewhere
[09:53] <tsdgeos> Saviq: want me to find them?
[09:53] <Saviq> tsdgeos, looks like we lost them, is all
[09:53] <Saviq> tsdgeos, got loads of warnings on the console when trying to activate
[09:54] <tsdgeos> weird
[09:54] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/implicitHeightCardArtOnly/+merge/225943
[09:54] <mhr3> Saviq, are you ok with bumping u8's build-dep on latest unity-api, yet not bumping the -impl dep yet? will allow us to land the changes separately
[09:55] <tsdgeos> Saviq: testDashContent has a few preview related tests too
[09:55] <Saviq> mhr3, sounds fine, yes
[09:55] <mhr3> Saviq, coolio, quick review of https://code.launchpad.net/~mhr3/unity-api/expansion-queries/+merge/225938 pls (just interface changes)
[09:55] <Saviq> tsdgeos, yeah, the tests are there, and pass, but previews never actually load
[09:55] <tsdgeos> oh
[09:57] <Saviq> mhr3, I'm just not too happy about "expansionQuery"
[09:57] <Saviq> mhr3, since it's not expansion any more
[09:58] <mhr3> Saviq, hm, well designs have either that OR the see more button.. so it kinda is
[09:58] <mhr3> but of course that can change too easily
[09:58] <Saviq> mhr3, will we enforce that?
[09:58] <mhr3> we might have to actually
[09:58] <Cimi> mzanetti, maybe setting live true only when the launcher is not hidden? https://code.launchpad.net/~mzanetti/unity8/make-launcher-icons-live/+merge/224116
[09:59] <mhr3> mikenagle_, ^?
[09:59] <Saviq> mhr3, will the expansion query always be in-scope, btw?
[09:59] <Saviq> mhr3, can it not open another scope?
[09:59] <mhr3> Saviq, it can, yes
[09:59] <Saviq> mhr3, shouldn't performQuery be on Scopes instead of Scope, then?
[09:59] <mzanetti> Cimi: we figured that even when live: true it only updates rendering if the icon changes, which basically never happens
[09:59] <mzanetti> Cimi: so I guess we can always leave it live: true in this case
[10:00] <mhr3> Saviq, no, if it does change the current scope, you don't want to loose that info, or to keep track of where to build a stack for that matter
[10:00] <mzanetti> Cimi: well, it happens only in one case that the icon changes, when the user longpresses it, and that's when we really want to update it... so no need to fiddle with the live property
[10:00] <Cimi> mzanetti, fine then
[10:03] <mzanetti> tsdgeos: Saviq: so we're ok with this? https://code.launchpad.net/~unity-team/unity8/scope-customizations/+merge/225823
[10:04] <Saviq> mzanetti, unless you tell me otherwise, nobody convinced me this is a bad approach
[10:04] <Saviq> mzanetti, benchmarking showed negligible difference
[10:04] <mzanetti> Saviq: difference between?
[10:04] <mzanetti> non-object vs object or object vs ScopeStyle?
[10:04] <Saviq> mzanetti, between trunk, default: null and default: Object({ })
[10:05] <Saviq> mzanetti, can try with actual ScopeStyle, sec
[10:05] <mzanetti> Saviq: as you have that running already, what would be the difference to using ScopeStyle {} ?
[10:05] <tsdgeos> Saviq: did you fix the comment about it not applying to previews and to departments?
[10:06] <Saviq> tsdgeos, yes, but need add a tryPreview to actually show it, we've no other way
[10:08] <Cimi> mzanetti, that branch doesn't build for me anyway
[10:08] <mzanetti> Cimi: which one?
[10:08] <Cimi> issues with scopes
[10:09] <Cimi> might be trunk
[10:09] <mzanetti> which branch? the launcher ones?
[10:09] <Cimi> yes
[10:09] <Cimi> yeah needs merge trunk
[10:09] <Cimi> but is fine
[10:09] <mzanetti> hmm,,, yeah. they might require a merge with trunk by now
[10:09] <Cimi> with trunk works
[10:10] <mzanetti> Cimi: want me to merge them? or hall we let CI do that?
[10:11] <Cimi> ci will do that
[10:11] <tsdgeos> Saviq: ok, so yeah no hard disagreement, i think i still prefer the null + if
[10:11] <Cimi> actually no
[10:11] <Cimi> mzanetti, sorry
[10:12] <tsdgeos> but it's a matter of style
[10:12] <Cimi> is launcher dnd that requires trunk
[10:12] <tsdgeos> since it seems we can't prove it's faster/slower
[10:15] <mzanetti> Cimi: ok, let me merge all of those laucnher branches with trunk
[10:15] <Cimi> wasn't initctl set-env GRID_UNIT_PX=18 to change pixel grid?
[10:16] <Cimi> global
[10:16] <mzanetti> Cimi: yeah, well, for things you start with init after this
[10:16] <mzanetti> Cimi: won't affect your current session I'd say
[10:16] <Saviq> mzanetti, tsdgeos, ScopeStyle has some impact http://pastebin.ubuntu.com/7764824/
[10:17] <Saviq> like .15 msec
[10:17] <mzanetti> is that 50ms on 1000 cards?
[10:18] <Saviq> mzanetti, 150ms on 1000 cards I'd say
[10:18] <mzanetti> compared to trunk, yes
[10:19] <mzanetti> anyways
[10:19] <Saviq> tsdgeos, so... I hate the if (foo) approach because of verbosity and the fact that you need to hardcode the default values in every single binding
[10:19] <mzanetti> so yeah... I gave my opinion, won't force you into anything
[10:19] <mzanetti> if you prefer to keep as is, I will approve
[10:20] <mzanetti> Saviq: are such tags bad?
[10:20] <mzanetti> 7.90+14.10.20140701.2-0ubuntu1 ?
[10:20] <mzanetti> 7.90+14.10.20140703.1-0ubuntu1 ?
[10:21] <Saviq> mzanetti, where'd you get them from?
[10:21] <Saviq> mzanetti, looks like you got tags and not merged trunk or so?
[10:22] <Saviq> mzanetti, those tags are valid in trunk
[10:22] <mzanetti> I got them after merging with trunk
[10:23] <Saviq> mzanetti, interesting, should not be ?
[10:23] <mzanetti> yeah... that's why I ask
[10:25] <Saviq> mzanetti, not sure how you got there, try deleting them and merging trunk again
[10:25] <mzanetti> Saviq: heh... I pushed to the branch, did a bzr tags again and the ? are resolved now
[10:26] <mzanetti> Saviq: except one in the middle
[10:26] <Saviq> mzanetti, yeah, that one's in trunk
[10:26] <mzanetti> ah ok
[10:26] <Saviq> mzanetti, not sure how that one happened either, but never got around to clearing it up
[10:28] <Cimi> mzanetti, I don't know if it a trunk issue or not merged with trunk
[10:28] <mzanetti> Cimi: I'm currently merging all the branches with trunk
[10:28] <Cimi> mzanetti, but https://code.launchpad.net/~mzanetti/unity8/launcher-update-item-glow/+merge/224266
[10:28] <Cimi> mzanetti, looks clip at top and bottom
[10:29] <Cimi> icons don't fill ubuntushape
[10:29] <Cimi> on the phone
[10:29] <mzanetti> oh. yeah... that might be an issue indeed, now that suru theme has landed
[10:29] <mzanetti> let me check
[10:30] <Saviq> mzanetti, so your opinion is we should use real ScopeStyle objects for the default? I'm worried that the impact will get bigger and bigger as ScopeStyle gets more things
[10:30] <mzanetti> ffs! If run.sh wouldn't kill my init all the time...
[10:31] <mzanetti> Saviq: nah... that seems to make too much of a difference indeed
[10:31] <Saviq> mzanetti, putting pressure on this bug would probably help 1222705
[10:31] <Saviq> bug #1222705
[10:31] <Saviq> mzanetti, tsdgeos, if you both dislike my approach, I'm losing here, so unless I get a third opinion I'll have to fold
[10:32] <tsdgeos> Saviq: i think having the null actaully helps in reading the code, knowing the object will come from somewhere
[10:32] <mzanetti> +1
[10:32] <tsdgeos> but yes the default in the if branch is not cool
[10:33] <tsdgeos> that's where qml should have a "whatever your default is"
[10:33] <Saviq> tsdgeos, I'd be fine with null if QML didn't fucking complain all the time
[10:33] <mzanetti> :D
[10:33] <tsdgeos> this has worked sometimes
[10:33] <tsdgeos> thoough it's also evil
[10:33] <tsdgeos> color: foo ? foo.bar : color
[10:33] <Saviq> yeah, that makes my eyes hurt
[10:34] <mzanetti> I'm not saying that I love this, but I think its less confusing than dummy objects with some properties. Unless they are clearly marked as such...
[10:35] <Saviq> mzanetti, as said, I will comment them of course
[10:36] <Saviq> mzanetti, the "context property" approach could be something, but other than reaching out of scope can't see how it'd help, and then I don't think it'd help with not having if(foo) anyway
[10:36] <Saviq> tsdgeos, btw, one thing I thought about for language changes, "inline components" is something I could use
[10:36] <Saviq> tsdgeos, like in a file declaring "here's the Label I want, but with those as defaults"
[10:37] <Saviq> tsdgeos, and then using that MyLabel in the same file (without a Loader)
[10:39] <Saviq> and without having to bind props in onLoaded or wherever
[10:40] <Saviq> tsdgeos, so, about readability... would a comment for the scopeStyle defaults be enough to help it?
[10:40]  * Saviq considers `foo ? foo.bar : "baz"` much less readable...
[10:40] <tsdgeos> Saviq: why?
[10:40] <tsdgeos> it's pretty clear on what it does
[10:41] <Saviq> tsdgeos, because it's useless
[10:41] <tsdgeos> and makes it usable from the outside
[10:41] <mzanetti> :D
[10:41] <tsdgeos> in case we ever need it
[10:41] <tsdgeos> sure deciding on a proper default is hard
[10:41] <Saviq> tsdgeos, my approach makes it just as usable from the outside
[10:41] <tsdgeos> true
[10:41] <tsdgeos> but less obvious it will be changed (even you can see it's not readonly)
[10:41]  * Saviq must look really desperate to justify his approach
[10:42] <tsdgeos> honestly i think you should move to the pattern we've been using everywhere
[10:42] <tsdgeos> and then calmly discuss what approach we want to follow as a guideline
[10:42] <tsdgeos> not as part of this review in particular
[10:42] <tsdgeos> stalls stuff unneededly
[10:46] <greyback> needlessly
[10:46]  * greyback had to check that 'unneededly' was actually not a word, but thinks it deserves to be one
[10:46] <Saviq> tsdgeos, yeah, like that will ever happen :P
[10:46] <tsdgeos> greyback: tx ;)
[10:47] <tsdgeos> Saviq: ^_^
[10:47]  * Saviq folds :|
[10:49] <tsdgeos> Saviq: i do honestly think we should have this discussion
[10:49] <tsdgeos> we can have it now if you want, but don't think it's the best time
[10:49] <Saviq> tsdgeos, we are, aren't we? ;)
[10:58] <Saviq> tsdgeos, btw, `property var foo: bar ? bar.baz : foo` doesn't really work well either, as results in stuff changing needlessly just after initialization
[10:58] <mhr3> Saviq, s/expansionQuery/linkQuery/ ?
[10:58] <tsdgeos> Saviq: what do you mean changing after initialization?
[10:58] <Saviq> mhr3, headerLink?
[10:59] <mhr3> fine
[11:00] <Saviq> tsdgeos, create → bar is null, foo gets default value; bar gets non-null, foo gets bar.baz value
[11:00] <mikenagle_> mhr3 - have emailed
[11:00] <mhr3> mikenagle_, yep, thx
[11:00] <Saviq> tsdgeos, if default and bar.baz are different (which they will often be), it will need new render
[11:00] <tsdgeos> Saviq: well that's the same that happens with your approach, no?
[11:01] <Saviq> tsdgeos, only if bar.baz is different than the value I said is default for the component I'm creating, not for the component I'm using
[11:01] <tsdgeos> i mean it will change from defaultObject.something to newObject.something
[11:01] <tsdgeos> ah sure
[11:01] <tsdgeos> so you're cheating ;)
[11:01] <karni> pete-woods: it's the second time I see this, any ideas? https://pastebin.canonical.com/113111/
[11:02] <tsdgeos> means we need to keep default synced to get this "benefit"
[11:02] <karni> pete-woods: rm'ing the directory fixes the problem, I'm just worried it's something worse then a "one time happened"
[11:02] <Saviq> tsdgeos, yeah, how's that cheating?
[11:02] <Saviq> tsdgeos, granted, if the default is coming from the theme in any case, probably doesn't matter
[11:03] <tsdgeos> Saviq: well part of your approach is that makes code easier to read/mantain, and you also say a benefit is less propperty changes, but that means we need to manually sync defaults everywhere which makes it less easy to read/mantain
[11:03] <pete-woods> karni: you'll need to talk to the click guys (I think mainly cjwatson) about that, package installation is out of my hands
[11:04] <Saviq> tsdgeos, we need to sync them manually anyway
[11:04] <Saviq> tsdgeos, just in one place per file with the default object
[11:04] <karni> pete-woods: thanks
[11:04] <pete-woods> np
[11:04] <Saviq> tsdgeos, vs. however-many-per-file with null (unless you go for a proxy property)
[11:05] <Saviq> but then you end up with:
[11:05] <Saviq> property var foo: null
[11:05] <Saviq> property color bar: foo ? foo.baz : "default"
[11:06]  * Saviq doesn't get how's that better than putting the default in foo directly ;P
[11:06] <mzanetti> Cimi: I've merged https://code.launchpad.net/~mzanetti/unity8/launcher-update-item-glow/+merge/224266 with trunk
[11:06] <mzanetti> Cimi: looks good imo
[11:06] <Cimi> mzanetti, waiting jenkins
[11:07] <Cimi> mzanetti, on desktop I don't have suru
[11:07] <mzanetti> Cimi: yeah, same here.... icons are empty (although I think I saw them already some days ago)
[11:07] <mzanetti> but on the phone its fine now
[11:07] <Saviq> mzanetti, Cimi wdym you don't have suru?
[11:08] <mzanetti> Saviq: using./run.sh the launcher icons are empty
[11:08] <mzanetti> not sure why
[11:08] <Cimi> or I simply have normal icons
[11:08] <Cimi> not suru
[11:09] <Cimi> circulas icons
[11:09] <Cimi> no suru theme
[11:09] <Cimi> so I can't test if they fill
[11:09] <tsdgeos> Saviq: let's not block on this, for me you can get it merged as it is if it works (which i haven't tried, i can if you want)
[11:09] <tsdgeos> and then discuss later if we want this everywhere or just here
[11:09] <tsdgeos> ok?
[11:10] <Saviq> tsdgeos, already changed
[11:10] <mzanetti> Cimi: all launcher branches merged with trunk
[11:10] <tsdgeos> Saviq: doh :/
[11:10] <tsdgeos> ok
[11:10] <Saviq> tsdgeos, but that's fine
[11:10] <tsdgeos> mzanetti: all yours then?
[11:10] <Cimi> mzanetti, almost all approved apart item glow
[11:11] <mzanetti> tsdgeos: ?
[11:11] <Saviq> mzanetti, I reverted to foo ? foo.bar : "baz"
[11:11] <Saviq> mzanetti, in the scope customs branch
[11:11] <mzanetti> ack
[11:11] <tsdgeos> mzanetti: i mean you were doing the review, no?
[11:11] <mzanetti> yeah
[11:12] <Saviq> mzanetti, I need to do a tryPreview, though, otherwise we can't see the previews being "affected" by the style
[11:12] <tsdgeos> Saviq: why?
[11:12] <tsdgeos> or you mean on tryXYZ?
[11:12] <Saviq> tsdgeos, yes
[11:12] <Saviq> tsdgeos, since we have no real preview anywhere in the tests...
[11:13] <Saviq> tsdgeos, I want one that will be mostly manual (the widgets themselves are tested fine)
[11:13] <tsdgeos> err
[11:13] <tsdgeos> what broke?
[11:13] <tsdgeos> Error: Unknown method return type: unity::shell::scopes::PreviewModelInterface*
[11:13] <mhr3> Saviq, updated unity-api and u8 branches, do you have a silo where the api changes could go, or should i ask for one?
[11:13] <tsdgeos> this used to work
[11:13] <Saviq> mhr3, I'll take care of that today, K?
[11:13] <mhr3> Saviq, awesome, thx
[11:14] <Saviq> mhr3, unless you really want it *now*, then have at it
[11:14] <Saviq> tsdgeos, yeah, that's what I meant, we managed to break the mock previews somehow
[11:14] <mhr3> Saviq, nope, but i need to leave for a few hours, so wanted to sort it out before i do
[11:14] <Saviq> mhr3, ok, I'll take care of it
[11:16] <mhr3> Saviq, here's mp list for -api http://paste.ubuntu.com/7765051/
[11:16] <Saviq> mhr3, ah, you didn't reply whether performQuery should be on Scopes, and not Scope  instead?
[11:16] <mhr3> Saviq, i did ^^^^
[11:16] <Saviq> hmm
[11:17] <Saviq> mhr3, not sure what info? you mean where it came from?
[11:17] <mhr3> yep
[11:17] <sil2100> Saviq: is silo 004 something big?
[11:17] <mhr3> Saviq, really the associated scope instance
[11:18] <Saviq> sil2100, transfer indicator, I wouldn't call it big
[11:18] <sil2100> Saviq: I guess it's not regression prone?
[11:18] <mhr3> Saviq, can't build much of a stack without that
[11:18] <Saviq> sil2100, not at all
[11:18] <sil2100> Love it
[11:19] <Saviq> mhr3, still not sure we need it, but your call, easier for me this way anyway :P
[11:19] <mhr3> Saviq, i think we do, plus openScope is emitted on the scope instance anyway
[11:20] <mhr3> not on ScopeS
[11:20] <Saviq> mhr3, ah, nasty :P
[11:20] <mhr3> s/nasty/makes sense/
[11:20] <mhr3> ftfy
[11:20] <Saviq> mhr3, we just need to forward it up anyway ;)
[11:21] <Saviq> /food
[11:21] <mhr3> do you? i thought you associate it with the view it came from
[11:27] <facundobatista> Holas
[11:28] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/fake_scopes_plugin_register_previewmodel/+merge/225956
[12:05]  * greyback going into mir land, may be offline a while
[12:15] <Saviq> tsdgeos, thanks, wonder how that broke
[12:15] <Saviq> mhr3, nope, we just push it up and put it on top of the list of scopes
[12:31] <mzanetti> Saviq: re: Not sure unity8 should do anything here. Libusermetrics should just not give up any data if it's disabled.
[12:31] <mzanetti> Saviq: I think that's what happens, which causes the infographics to dispay "No data sources available"
[12:33] <Saviq> mzanetti, ah then that's gonna be fixed by https://code.launchpad.net/~cimi/unity8/infographics-new-lightdm/+merge/223221
[12:34] <mzanetti> ah ok
[12:44] <karni> mhr3: do you know how works on libunity-scopes2 package?
[12:47] <karni> cwayne: I asked mhr3 ↑ so we can better understand if the scope.hook needs fixing.
[12:49] <om26er> mzanetti, Hello!
[12:49] <cwayne> the click hook's not broken
[12:50] <mzanetti> om26er: hi
[12:50] <om26er> mzanetti, what do I need to do to add the icon for a single qml file in the launcher ?
[12:50] <karni> cwayne: even though it says nothing about leaf-net (or others)?
[12:50] <om26er> need to add a very simple app to the launcher that we can trust will launch during the test.
[12:50] <Saviq> mzanetti, I pushed a few commits still to the scope-customizations branch
[12:50] <mzanetti> om26er: well, its the same as I showed you last time
[12:51] <mzanetti> Saviq: ack. did you put it back to Needs review?
[12:51] <Saviq> mzanetti, now I did
[12:51] <mzanetti> om26er: is there any troubles you're facing with that?
[12:51] <om26er> mzanetti, I used that to put messaging-app in the launcher, but didn't know the entries for a new app, that never appeared in the launcher
[12:52] <om26er> https://code.launchpad.net/~om26er/unity8/launcher_integration_test/+merge/224701
[12:52] <om26er> mzanetti, I ported the gdbus call you gave to python, it works but its relying on real apps (in this case messaging-app) but a bug in the messaging-app may fail that test.
[12:53] <mzanetti> om26er: then you need to create an app
[12:53] <mzanetti> om26er: well, all you need is a manifest.json, appname.json and the qml file
[12:53] <mzanetti> om26er: then you can install that as a click package
[12:54] <mzanetti> om26er: we can't show random icons in the launcher. it has to be related to an application
[12:55] <om26er> mzanetti, I can create a .click from QtCreator but installing it during the test can be tricky.
[12:55] <mzanetti> om26er: hmm... why is that?
[12:56] <mzanetti> om26er: you just need to call "click install --user=phablet packagename.click"
[12:56] <om26er> mzanetti, just like that ?
[12:56] <mzanetti> yeah, well, replace "packagename" with what it is, but yes
[12:57] <om26er> mzanetti, ok, thanks. I'll work on that.
[12:57] <mzanetti> om26er: let me know if you have troubles
[13:02] <karni> mhr3: ignore my last question about the scope.hook
[13:13] <tsdgeos> Saviq: why WIP here? https://code.launchpad.net/~aacid/unity8/implicitHeightCardArtOnly/+merge/225943
[13:13] <Saviq> tsdgeos, it's ACKed already, fat fingers
[13:13] <tsdgeos> ah
[13:14] <tsdgeos> didn't get the other email
[13:18] <Saviq> mzanetti, on https://code.launchpad.net/~mzanetti/unity8/new-header/+merge/224585 please bump the uitk dep to >= 0.1.49
[13:18] <mzanetti> Saviq: ack
[13:21] <mzanetti> Saviq: done
[13:22] <Saviq> mzanetti, thanks
[13:56] <Saviq> mzanetti, you need to merge trunk in new-header
[13:56] <Saviq> mzanetti, debian/control conflicted
[13:56] <Saviq> mzanetti, and you need more bumps around it
[14:06] <mzanetti> Saviq: merged, can you please check the version bumps
[14:06] <Saviq> mzanetti, yup, doing
[14:08] <Saviq> mzanetti,
[14:08] <Saviq> > grep toolkit debian/control
[14:08] <Saviq>                qtdeclarative5-ubuntu-ui-toolkit-plugin (>= 0.1.49) | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles (>= 0.1.49),
[14:08] <Saviq>          qtdeclarative5-ubuntu-ui-toolkit-plugin (>= 0.1.48) | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles (>= 0.1.48),
[14:08] <Saviq>          qtdeclarative5-ubuntu-ui-toolkit-plugin (>= 0.1.48) | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles (>= 0.1.48),
[14:08] <mzanetti> oh.. right
[14:09] <mzanetti> Saviq: ok. should be better now
[14:11] <Saviq> mzanetti, ack
[14:12] <mzanetti> cheers
[14:41] <Saviq> mzanetti, dednick, one of you needs to merge with the other:
[14:41] <Saviq> Text conflict in debian/control
[14:41] <Saviq> Text conflict in qml/Panel/Panel.qml
[14:41] <Saviq> Text conflict in tests/qmltests/Panel/tst_Panel.qml
[14:41] <Saviq> https://code.launchpad.net/~nick-dedekind/unity8/indicator.call-hint and https://code.launchpad.net/~mzanetti/unity8/new-header
[14:42] <dednick> mzanetti: i'll merge
[14:42] <Saviq> dednick, sounds like it'll be easier this way indeed
[14:42] <Saviq> dednick, mzanetti's is mostly red in Panel
[14:43] <mzanetti> dednick: ok, thanks. makes it a good checkpoint for you to make sure if I forgot to remove anything
[14:44] <mzanetti> well, didn't forget, that is :)
[14:54] <dednick> mzanetti: hm. the required branch has landed right?
[14:54] <mzanetti> dednick: not sure
[14:54] <mzanetti> Saviq: do you know?
[14:55] <Saviq> dednick, UITK? in proposed
[14:55] <Saviq> dednick, or silo 16
[14:57] <dednick> Saviq: ah. didn't realise they had a staging
[14:57] <Saviq> dednick, yeah :|
[14:57] <Saviq> dednick, actually proposed only, as we needed to bump changelog in proposed for it
[14:58] <karni> Saviq: do you know if designers ever considerered leaving the preview like you leave a regular app? I find myself constantly scipe to right when previewing
[14:58] <Saviq> karni, it's already happening
[14:58] <Saviq> karni, dash will effectively become an app
[14:58] <Saviq> one that you can't close, is all
[15:00] <karni> Saviq: but a preview will be swipe-able? :)
[15:00] <dednick> oh my word. we can cancel a search?!
[15:00] <karni> Saviq: or leave preview with back button lol ;D
[15:00] <Saviq> dednick, ;D
[15:01] <Saviq> karni, ah you mean you're swiping right to go back to dash?
[15:01] <Saviq> karni, no, button as today
[15:01] <Saviq> karni, what you're suggesting would mean that preview would be a ~separate app
[15:01] <karni> Saviq: yeah, swiping right all the time and then "d'uh! it's a preview"
[15:02] <karni> Saviq: in theory, perhaps not in practice, but I guess that wouldn't be easy. or maybe a "~separate app", yes
[15:02] <pete-woods> Cimi: hey, your infographics branch seems to be failing the tests because of an extra newline and the end of Infographics.qml
[15:02] <karni> Saviq: just wondering if design ever thought about it
[15:02] <karni> for consistency sake
[15:02] <Saviq> karni, I think it could become a little too much
[15:03] <Saviq> karni, imagine you'd do that 5 times, opening different previews
[15:03] <karni> Saviq: too bad, this gesture is very intuitive :)
[15:03] <dednick> Saviq: do i need to resubmit with pre-req?
[15:03] <karni> Saviq: I prever that than reaching with my right thumb to upper left. just saying :D
[15:03] <Saviq> dednick, nah that's fine
[15:03] <karni> *prefer
[15:03] <Saviq> karni, you'd end up with 5 previews in the stack
[15:03] <dednick> Saviq: ok, i've pushed
[15:04] <Saviq> karni, right, the back button placement was debated quite a bit already
[15:04] <karni> Saviq: k, gotcha. /me stops being PITA ;)
[15:04] <Saviq> karni, you're not, not at all
[15:04] <Saviq> but the right-edge gesture is toggle between apps, not "back"
[15:04] <karni> gotcha :)
[15:05] <Saviq> karni, we can't have both on the right edge...
[15:05] <karni> Saviq: yeah, I meant sort of separate app. not making it a "back" gesture. I get your point :)
[15:05] <Saviq> karni, truth be told, there's space for behaviour like that
[15:06] <Saviq> karni, like for example I'd rather see multiple browser windows than tabs within the browser
[15:07] <karni> Saviq: interesting
[15:07] <karni> now that switching is so easy, right? yeah, that's an idea
[15:08] <Saviq> karni, I never missed browser tabs on my phone, for example, and constantly get lost on android
[15:08] <Saviq> mzanetti, will you have time for the last commits on scope-customizations/
[15:08] <Saviq> ?
[15:09] <mzanetti> yeah... can do it now
[15:09] <Saviq> thanks
[15:10] <Saviq> karni, so, in theory it's possible to have previews like that, the difference is that it's very explicit to open a new tab / browser window
[15:10] <karni> Saviq: right..
[15:10] <Saviq> karni, whereas opening a preview is just clicking on a link
[15:10]  * karni nods
[15:10] <Saviq> karni, I rarely expect that to open a new window
[15:10] <mzanetti> Saviq: just this? http://bazaar.launchpad.net/~unity-team/unity8/scope-customizations/revision/1031
[15:10] <Saviq> mzanetti, I don't think you saw 1029→1031
[15:11] <Saviq> mzanetti, you can test 1030 with lp:~aacid/unity8/fake_scopes_plugin_register_previewmodel
[15:11] <Saviq> mzanetti, tryDash and go to a preview
[15:12] <Saviq> in the red/blue scope that is
[15:12] <Saviq> mzanetti, before preview would have grey text, now → blue
[15:15] <mzanetti> that scope is freakin ugly
[15:15] <mzanetti> :D
[15:16] <mzanetti> but I guess it's its purpose
[15:18] <Saviq> mzanetti, indeed ;)
[15:34] <greyback> bregma: can you remind me - is there currently a cursor visible in unity8 on desktop?
[15:35] <bregma> greyback, there is on my machines -- all Intel hardware
[15:36] <greyback> bregma: ok thanks
[15:37] <mhr3> Saviq, well, that will need changing, will have to keep stack... although i'm not sure if you really need to keep it per-scopeview... maybe not
[15:37] <greyback> bregma: would you know if it is unity8 that draws that cursor, or unity-system-compositor?
[15:37] <Saviq> mhr3, definitely not
[15:37] <bregma> greyback BTW, your right-edge PPA broke u-s-c on my test machines last night, in case you were wondering
[15:37] <mhr3> karni, tbh i'm not really sure how that works, so if you know now, please enlighten me :)
[15:37] <greyback> bregma: I've pushed a fix for that, it should work now
[15:37] <Saviq> mhr3, there will be a single stack, the root of which will be the list of scopes, not a single scope
[15:38] <Saviq> mhr3, stuff's in silo 18 btw
[15:38] <bregma> greyback, it's the hardware cursor, enabled by u-s-c
[15:38] <karni> mhr3: sorry, context?
[15:38] <bregma> there's a command-line option
[15:38] <mhr3> karni, click scope hook
[15:38] <greyback> bregma: ok. our qtcomp PPA not touching USC, so that /should/ just work as normal. unity8 does change tho
[15:38] <karni> mhr3: ah, I think I said to ignore that :D haha
[15:38] <karni> mhr3: well, scopes can define in manifest.json a scope hook
[15:38] <karni> mhr3: which basically instructs the system how/where to install the scope
[15:39] <karni> mhr3: /usr/share/click/hooks contains definitions of hooks
[15:39] <karni> specifically, scope.hook that I was interested in
[15:40] <karni> mhr3: turns out (and I agree with your +Needs Information on a MP from michi today), that /leaf-net/$APP_ID directory has nothing to do with the pattern defined in scope.hook
[15:40] <bregma> greyback, if Unity8 wants to start rendering the cursor, that's just fine
[15:41] <karni> mhr3: and that is what I needed to know. I agree this MP needs info, who needs to create that /leaf-net/$APP_ID dir
[15:41] <greyback> bregma: quite the opposite, I was hoping to not have to right now :)
[15:41] <greyback> bregma: but I wasn't seeing a cursor when testing the phone-right-edge ppa so started adding support for it
[15:42] <greyback> but now I don't think it's necessary, USC should be drawing it
[15:42] <karni> mhr3: do you know if departments are in utopic (not -proposed)?
[15:42] <mhr3> karni, not sure the hook even has a capability to look at the security profile
[15:42] <bregma> USC enables it, it's actually drawn by the video driver if it supports it -- and not all of them do
[15:42] <karni> mhr3: a question I never know how to answer. perhaps instead you can tell me how to *find* the answer instead? :)
[15:42] <mhr3> karni, which will mean that registry has to do it
[15:43] <mhr3> karni, you look at what's last promoted image :)
[15:43] <mhr3> karni, which is 113, so yes, it's there
[15:43] <bregma> greyback, some day the cursor rendering will need to be moved into a Mir server, but that day does not have to be today
[15:43] <greyback> bregma: ok. Then I'll leave the cursor to the USC for now. Can later add support
[15:43] <bregma> it's a plan
[15:43] <greyback> bregma: racarr is working on that
[15:43] <karni> mhr3: where do you check the latest promoted image? the mailing list, or the channel json?
[15:44] <greyback> bregma: software rendering of cursor when hw doesn't do it
[15:44] <mhr3> karni, i just looked at top of the landing sheet, but yes, it's in those places as well
[15:44] <karni> aha, thank you :)
[15:52] <mhr3> Saviq, want me to run through test plan on 018?
[15:52] <Saviq> mhr3, UITK didn't migrate proper yet
[15:52] <Saviq> mhr3, and I was about to do that when it does
[15:53] <mhr3> Saviq, not like proposed wasn't enabled on the images ;)
[15:53] <Saviq> mhr3, four eyes always better'n'two!
[15:53] <Saviq> mhr3, it's not
[15:53] <mhr3> Saviq, it's not?
[15:53] <Saviq> mhr3, nope
[15:53] <mhr3> what?
[15:53] <mhr3> i always thought it is
[15:54] <mhr3> cause we have very clear names... like utopic-proposed
[15:54] <Saviq> mhr3, rrright
[15:54] <mhr3> but yea... i remember now that someone already enlightened me about that
[15:54] <Saviq> mhr3, that's the proposed phone image, not the phone image built from proposed...
[15:54] <mhr3> yea...
[15:55] <Saviq> kinda broken indeed
[15:56] <Saviq> ok I'm gonna stop staring at excuses...
[15:56] <Saviq> it'll migrate 1s after, of course
[15:56] <mhr3> heh
[15:56] <mhr3> yea, it always does that
[16:11] <karni> mhr3: what's the address of the sheet? I'm on "Self service CI" and I think that's the old one, locked down from edits.
[16:11] <karni> mhr3: I wanted to learn revno of -proposed this time ;P
[16:12] <karni> mhr3: k, just found the mail from Łukasz
[16:14] <mhr3> karni, eh, yea.. sorry, i'm slow :P
[16:15] <karni> np!
[16:18] <mhr3> Saviq, migrated :)
[16:18] <Saviq> mhr3, yup, saw that
[16:19] <Saviq> still, ports doesn't know yet...
[16:21]  * tsdgeos waves
[16:30] <mhr3> Saviq, hm, scope title missing on temp scopes that don't have custom icon
[16:30] <mhr3> Saviq, like the app store
[16:36] <mhr3> Saviq, and previewing stuff in carousel previews always the first item, no matter what i tap
[16:38] <Saviq> mhr3, ok, so NACK
[16:38] <Saviq> mhr3, I'll deal with it first thing tomorrwo
[16:38] <mhr3> Saviq, yep, needs fixing
[16:38] <Saviq> mhr3, weird, though :|
[16:39] <Saviq> both of these usecases I tested
[16:39] <mhr3> Saviq, refactored too much? :)
[16:39] <Saviq> not to mention they're auto-tested
[16:40] <mhr3> hmm
[16:41] <Saviq> well, not the title
[16:41] <Saviq> anyway
[16:41] <Saviq> not today
[16:42] <mhr3> sure, have a nice evening!
[16:47] <cwayne> btw i showed off the customizations we can do with that branch, and was asked a bunch about changing just the color of the header, rather than the whole page
[16:48] <cwayne> Saviq: just fyi ^, seems likely that'll be a requirement sooner rather than later :)
[16:48]  * cwayne is at least happy the uitk finally made it
[16:59] <Saviq> cwayne, yeah, it's on the TOOD
[16:59] <Saviq> TODO
[16:59] <Saviq> cwayne, all of it will happen within weeks tops
[17:03] <greyback> cd
[17:05] <Saviq> HUH
[17:05] <greyback> robru: could I grab some of your time for some packaging advice/review?
[17:06] <robru> greyback, sure, got a branch?
[17:06] <greyback> robru: I made some major changes to lp:qtmir packaging, to add desktop support
[17:06] <robru> greyback, is it in trunk already?
[17:07] <greyback> robru: yes it's in trunk
[17:07] <robru> greyback, k, checking
[17:07] <greyback> robru: thank you
[17:07] <robru> greyback, you're welcome
[17:10] <robru> greyback, hmmm, I don't think you want qtdeclarative5-qtmir-plugin to 'Provides: qtmir', do you? It means that if you 'apt-get install qtmir' you can satisfy it with either qtmir-android, qtmir-desktop, or qtdeclarative.
[17:10] <greyback> robru: indeed I do not
[17:12] <robru> greyback, other than that it looks mostly sane to me, still checking a bit though
[17:13] <robru> greyback, hmmm, not sure about those .install files, seems to me that will result in the same identical files being shipped in those two packages...
[17:14] <robru> greyback, what exactly is the difference between android and desktop versions? is it just the arch it's compiled for or are there serious compile-time changes happening in the code?
[17:14] <greyback> robru: there are compile time differences in the code
[17:15] <robru> greyback, have you tested that you can actually build this and the Right Stuff gets built into both packages?
[17:15] <greyback> robru: yes and yes
[17:15] <robru> ok
[17:15] <greyback> robru: I was inspired by qtubuntu, it does the same thing, for exact the same reason
[17:16] <robru> greyback, oh wow, what's going on in debian/rules? why this tmp1 and tmp2 stuff?
[17:17] <greyback> robru: we need to rebuild the same code, with a compile time switch turned on in qtmir-desktop, and turned off in qtmir-android
[17:17] <greyback> qtmir-android will be installed only on phone/tablet devices (with Open GLES). qtmir-desktop on desktop (with desktop GL)
[17:18] <robru> yeah
[17:18] <greyback> robru: I know, it's a bit nuts. But it's only solution we had for qtubuntu, so I copied the approach for qtmir
[17:18] <robru> greyback, I have an idea to simplify this, hang on
[17:18] <greyback> robru: cool, would love to hear it
[17:20] <robru> greyback, wait, if I'm reading this right, then it looks like on armhf you are building *both* desktop and android bits, but on other arches you only build desktop bits... is that right?
[17:20] <greyback> robru: that is correct actually. Sorry, I always forget that
[17:21] <robru> greyback, hrm, yeah on my first reading I was thinking it was mutually exclusive, so I was going to do just one if/else at the beginning and then merge all the following if/else blocks to just use a single call with a single (pre-determined) variable. but if you need to actually run both, it doesn't work...
[17:31] <robru> greyback, https://code.launchpad.net/~robru/qtmir/packaging-simplification/+merge/226012 it's not as much of a simplification as i'd hoped but let me know what you think of this
[17:32] <robru> also I fixed the provides.
[17:32] <greyback> robru: looks good to me though. I'll happily accept anything to improve the readability :)
[17:33] <greyback> robru: very much appreciated.
[17:33] <greyback> thanks for proofing it
[17:33] <robru> greyback, you're welcome.
[17:33] <robru> greyback, need a silo then?
[17:35] <greyback> robru: we have a silo already, thanks
[17:35] <robru> greyback, oh, add my MP to it then ;-)
[17:35] <greyback> robru: will do
[18:56] <Saviq> mhr3, btw, fixed carousel, header is weird... it looks like the UITK header doesn't like updates
[19:58] <mhr3> Saviq, :/
[20:03] <mhr3> Saviq, forgot to add https://code.launchpad.net/~unity-team/unity8/scopes-mocks-v2/+merge/225940 to 018
[20:26] <Saviq> mhr3, actually fixed now
[20:31] <Saviq> mhr3, hmm why all the newline changes?
[21:30] <mhr3> Saviq, 1014. Consolidate code style of the scope mock
[21:31] <Saviq> CRAP
[21:31] <Saviq> reconf
[21:37]  * Saviq wants to simplify the mocks...'
[21:38] <Saviq> mhr3, fwiw, we're leaning towards /* */ instead of Q_UNUSED, the latter usually ends up being left around even when the param is used after all
[21:38] <mhr3> Saviq, but it has Q_ prefix, clearly it's better! :P
[21:39] <Saviq> ;)
[21:39] <mhr3> but ok noted
[21:39] <Saviq> I totally agree ;)