[07:13] <tsdgeos> landing \o/
[07:50] <dholbach> hiya
[07:50] <dholbach> can sombody please take a look at https://code.launchpad.net/~ubuntu-mate-dev/compiz/mate-consistent-keybindings/+merge/258251?
[07:51] <dholbach> it's in the sponsoring queue, so I thought I'd prod you guys about it :)
[08:07] <tsdgeos> mzanetti: so should we start another landing?
[08:22] <tsdgeos> pstolowski: it seems that at the end my landing took predence over the concierge one?
[08:26] <pstolowski> tsdgeos, hmm, indeed
[08:26] <pstolowski> tsdgeos, i'll rebuild
[09:42] <dholbach> hey bregma, do you know somebody who could take a look at https://code.launchpad.net/~ubuntu-mate-dev/compiz/mate-consistent-keybindings/+merge/258251?
[09:42] <tsdgeos> dandrader: something is borked at https://code.launchpad.net/~dandrader/unity8/app-state-handling/+merge/258653
[09:42] <tsdgeos> there's a few [09:43] <dandrader> tsdgeos, ok, will check it more closely. maybe I didn't catch all conflicts
[09:45] <dandrader> tsdgeos, I think it's a bug in launchpad's web diff view
[09:46] <dandrader> tsdgeos, ah, it must be because its prerequisite has conflicts with trunk
[09:46] <tsdgeos> ah, can be
[09:47] <tsdgeos> i also marked those
[10:11] <bregma> dholbach, I'll be working my way through all the outstanding Compiz MPs over the next couple of days:  I just got back from a couple weeks of vacation and things piled up
[10:11] <dholbach> <3
[10:11] <dholbach> thanks a lot bregma
[10:16] <mzanetti> tsdgeos, hey, can you please install the nichtlustig scope and tell me if that's a bug in unity8 or in the scope?
[10:17] <tsdgeos> mzanetti: E_NO_CONTEXT
[10:17] <mzanetti> erm... huh?
[10:18] <mzanetti> tsdgeos, it doesn't show anything?
[10:18] <tsdgeos> mzanetti: what's the nichtlusting scope?
[10:18] <dandrader> tsdgeos, no the diff looks correct. had to redo the stack of commits.
[10:18] <tsdgeos> is it on the shop?
[10:18] <dandrader> tsdgeos, s/no/now
[10:19] <mzanetti> tsdgeos, yes
[10:19] <mzanetti> tsdgeos, this is the card definition it uses: https://developer.ubuntu.com/en/scopes/guides/scopes-customization-branding/
[10:19] <mzanetti> wrong link
[10:19] <mzanetti> E_TOO_MANY_SIMULTANEUS_CHATS
[10:19] <mzanetti> this one: http://bazaar.launchpad.net/~mzanetti/+junk/nichtlustig-scope/view/head:/src/scope/query.cpp#L26
[10:20] <mzanetti> now the question is why the spacings between the tiles are broken
[10:26] <tsdgeos> mzanetti: ok, give me a sec
[10:29] <tsdgeos> mzanetti: so what's wrong exactly?
[10:29] <tsdgeos> the empty spacing?
[10:29] <tsdgeos> or?
[10:34] <mzanetti> tsdgeos, yeah
[10:34] <mzanetti> tsdgeos, it's more... first I'd say the spacing is too big.
[10:34] <mzanetti> tsdgeos, sometimes though, it's missing completely
[10:35] <mzanetti> refresh the scope and it'll change
[10:35] <tsdgeos> not here, it's always the same
[10:36] <mzanetti> tsdgeos, scroll down the scope
[10:36] <mzanetti> tsdgeos, also, you'll see cachebuffer operating too early and tiles disappear before the are leaving the scene
[10:36] <tsdgeos> not here
[10:36] <tsdgeos> mzanetti: are you on rtm or vivid?
[10:36] <mzanetti> vivid
[10:37] <tsdgeos> ok, going back to scopes and using the manage scopes got me the bad spacing
[10:37] <tsdgeos> can't get the tiles to disappear
[10:37] <tsdgeos> but that may happen at some point if they're wrongly layouted
[10:37] <mzanetti> http://i.imgur.com/d7tmwlz.png
[10:38] <mzanetti> this is when I scroll to the bottom
[10:38] <mzanetti> 100% reproduceable by doing:
[10:38] <mzanetti> * favorite the scope
[10:38] <mzanetti> * go to it using horizontal swipes
[10:38] <mzanetti> * pull down to refresh it
[10:39] <mzanetti> then slowly scroll to the bottom, watch topmost ones disappear too early, see spacing broken for bottom cards
[10:41] <tsdgeos> mzanetti: can i get the scope for the desktop please?
[10:41] <tsdgeos> :/
 mzanetti: can i get the scope for the desktop please?
 i guess we're at the point already that some stuff is much easier to get on the phone than on the desktop
[10:53] <tsdgeos> ok compiled manually
[10:53] <tsdgeos> i'll have a look at least as to why there's the empty space
[11:05] <mzanetti> not sure why my IRC highlight has gone today
[11:05] <mzanetti> tsdgeos, you still need something?
[11:10] <mzanetti> tsdgeos, also I'd have another one of those questions. If you install the "südwestpresse" scope (search for "swp" in the store). then open a preview, you'll see that the image in the header is too large
[11:10] <mzanetti> again I think even if the scope developer provides an image that doesn't fit properly, we should probably set the size ourselves somehow
[11:14] <tsdgeos> mzanetti: no, it's ok
[11:15] <tsdgeos> i've a fix at least for the empty space
[11:15] <mzanetti> tsdgeos, cool :)
[11:16] <tsdgeos> not sure if that'll fix the clipping
[11:16] <tsdgeos> i'm hoping it will
[11:24] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/card_height_overlay_header/+merge/258756
[11:25] <mzanetti> tsdgeos, will this still work for cards that have a headeroverlay AND and a summary?
[11:25] <mzanetti> given that the summary is still outside the art in that case
[11:26] <tsdgeos> mzanetti: the if for the summary is higher in the chain
[11:26] <mzanetti> ack
[12:52] <tsdgeos> mzanetti: have you tried the patch?
[13:03] <tsdgeos> mzanetti: also answered https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1453546
[13:46] <mzanetti> tsdgeos, well, regardless if it's intentional or not... it's bad
[13:46] <mzanetti> IMHO, that is
[13:46] <tsdgeos> why ?
[13:47] <tsdgeos> how would you use a gradient in the foreground color or in the divider line?
[13:47] <mzanetti> because for example the swp scope. the blue in the logo can't be the same blue as the one of the back arrow
[13:47] <mzanetti> tsdgeos, not necessarily a gradient... but a color:///#aarrggbb
[13:47] <tsdgeos> well that works of course
[13:47] <tsdgeos> just don't use color:///
[13:47] <mzanetti> tsdgeos, not for me
[13:48] <mzanetti> ah... ok... then it's the doc that sucks
[13:48] <mzanetti> mhall119, think we can improve that? ^^
[13:49] <tsdgeos> mzanetti: i don't know why it sucks
[13:49] <mzanetti> the docs say one should use color:///#aarrggbb, but apparently only "#aarrggbb" works
[13:50] <tsdgeos> mzanetti: no, one should use color://// in the fields that support background uris
[13:50] <tsdgeos> read the part i quoted on the bug
[13:50] <mzanetti> and which fields are that?
[13:50] <mzanetti> "some" is really not precise enough imo
[13:50] <mhall119> mzanetti: where is that?
[13:50] <tsdgeos> agreed
[13:51] <mzanetti> mhall119, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1453546
[13:51] <tsdgeos> mzanetti: actually it's pretty defined i think
[13:51] <tsdgeos> the ones that say "background scheme" it's a "background scheme" (i.e. the color:///) stuff
[13:51] <tsdgeos> the rest just say "color"
[13:51] <tsdgeos> and color is "red" or "#aarrggbb"
[13:52] <tsdgeos> but i guess it could be improved
[13:52] <tsdgeos> it took me a while to understand it and i kind of know what it says
[13:52] <mzanetti> also it should say that for !some one should use either an svg color name or a "#aarrggbb" value
[13:52] <mzanetti> but I'm so sure I tried that... it only painted black all the time for me
[13:52] <mzanetti> let me try again
[13:53] <tsdgeos> well then that's a bug
[13:55] <mzanetti> it works... seems I didn't try that
[13:57] <tsdgeos> so i guess it needs a rewording
[13:57] <tsdgeos> saying "in the above list color means bla and background scheme means blo"
[13:58] <mzanetti> yes
[13:59] <mzanetti> tsdgeos, why making it different though...
[13:59] <mzanetti> it should always be the same, except background one additionally supporting gradient:///
[13:59] <mzanetti> imo
[14:00] <tsdgeos> mzanetti: and images in urls
[14:01] <tsdgeos> i don't know i didn't do that spec
[14:01] <tsdgeos> i'm just telling you what it says and how we implemented it
[14:01] <tsdgeos> honestly i have no opinion
[14:01] <mzanetti> sure.
[14:07] <dandrader> greyback, what optimization does a const int parameter bring?
[14:14] <greyback> dandrader: it's more for humans here tbh. Without the compiler will usually have to copy the parameter, so for objects that can be a cost. For int, it's pretty cheap, so not much of a gain. But I like using const whenever possible
[14:14] <greyback> http://www.gotw.ca/gotw/081.htm is nice summary
[14:18] <pstolowski> tsdgeos, hey, i guess you want somebody from unity8 team to top-approve https://code.launchpad.net/~aacid/unity8/edit_reviews/+merge/258623 ?
[14:18] <tsdgeos> pstolowski: i'd like to yeah
[14:18] <tsdgeos> greyback: const won't stop the compiler doing a copy of the object, const & will
[14:19] <pstolowski> tsdgeos, i will prepare a silo with our stuff
[14:19] <tsdgeos> also it's actaully slower to pass POD as const & than just by copy
[14:19] <dandrader> greyback, I don't see the point of a "const int". But I do see it for "const FooStruct&". In the latter you avoid copying over a struct. but and int? nothing is smaller than an int
[14:20] <greyback> tsdgeos: you're right
[14:20] <tsdgeos> greyback: http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/ is a very nice article about it
[14:20] <tsdgeos> when you have days to digest it all
[14:20] <greyback> tsdgeos: what say you? "const int" vs "int"
[14:20] <tsdgeos> i went straight into the conclusions :D
[14:21] <tsdgeos> greyback: no i mean const int & vs int
[14:21] <tsdgeos> const int vs int i'd say it's the same
[14:22] <greyback> dandrader: then it's merely a hint for humans
[14:22] <greyback> but one I like
[14:22] <tsdgeos> and the compiler in case you try to change it :D
[14:23] <tsdgeos> cimi: can you do https://code.launchpad.net/~aacid/unity8/edit_reviews/+merge/258623  ?
[14:23] <dandrader> I would say that "const int" param is a copy of an int that the function code can't modify. no optimization
[14:23] <cimi> tsdgeos, sure
[14:23] <tsdgeos> cimi: cheers
[14:24] <dandrader> greyback, I don't know. I've never seen a function taking a "const int".....
[14:24] <greyback> dandrader: yep, we've already established it's not a performance optimization, it's a hint for human & compiler
[14:25] <dandrader> greyback, I think this hint does more harm than good, as it bloats the signature for no real benefit
[14:26] <dandrader> I mean, who care is the function implementation changes the int it gets as a parameter?
[14:26] <greyback> dandrader: 6 chars != bloat in my book
[14:26] <dandrader> *cares if
[14:26] <pstolowski> mzanetti, hey, ok if i request a silo with unity8 branch and related stuff for review editing functionality?
[14:27] <mzanetti> pstolowski, sure. can we add some little more stuff into that?
[14:27] <mzanetti> pstolowski, I would help with the testing abviously
[14:29]  * mterry upgrades to wily
[14:29] <pstolowski> mzanetti, sure
[14:32] <mzanetti> tsdgeos, approved your branch. fixes the nichtlustig scope spacings
[14:32] <mzanetti> tsdgeos, however, I can still see cards disaappear too early
[14:32] <tsdgeos> damn
[14:32] <tsdgeos> ok, i'll try to reproduce harder
[14:35] <mzanetti> tsdgeos, I can only repro it with the nichtlustig scope... not for example with the xkcd one that also uses header-overlay with no summary
[14:39] <pstolowski> tsdgeos, can you bump the version with your edit_reviews branch? i need to make click scope depend on that, otherwise the scope will break
[14:49] <tsdgeos> mzanetti: it's probably not a journal?
[14:49] <tsdgeos> pstolowski: bump the version of what?
[14:49] <pstolowski> tsdgeos, unity8
[14:50] <tsdgeos> doesn't every release do that?
[14:50] <tsdgeos> or you mean bump to 8.03 ?
[14:50] <pstolowski> tsdgeos, sure, but i need the number upfront to update my control file :)
[14:51] <mzanetti> tsdgeos, right...
[14:51] <tsdgeos> pstolowski: not sure what i have to do then :D
[14:51] <tsdgeos> mzanetti: ↑↑↑ ?
[14:52] <pstolowski> tsdgeos, actually.. i wonder if it's a good idea to introduce such dependency
[14:52] <pstolowski> tsdgeos, i've never done that before
[14:52] <pstolowski> tsdgeos, meh, scratch that
[14:52] <tsdgeos> pstolowski: ok :D
[14:53] <pstolowski> mzanetti, feel free to add more stuff to line #70
[14:53] <mzanetti> pstolowski, ack
[14:54] <mzanetti> pstolowski, I see this targetting wily. how are you handling that?
[14:54] <mzanetti> does that mean editing reviews will only work in november?
[14:55] <mzanetti> MacSlow, hey... so, about that shellrotation AP tests. what's the status?
[14:55] <tsdgeos> which raises the question of
[14:56] <tsdgeos> shall we jump to wily or what?
[14:56] <mzanetti> yeah... current situation is not really clear at all
[14:56] <MacSlow> mzanetti, ready for more review eyes
[14:57] <mzanetti> MacSlow, has that long standing issue been fixed now?
[14:58] <MacSlow> mzanetti, qml-cache issue can be avoided by unsetting QV4_ENABLE_JIT_CACHE... this isn't really an issue that branch is meant to solve.
[14:58] <mzanetti> ah ok
[14:58] <MacSlow> mzanetti, apart from that I've 100% success-rate
[14:58] <mzanetti> ok. sounds good
[14:58] <mzanetti> thanks
[14:59] <MacSlow> mzanetti, I'll just hope to dig myself 100% into unity8-launcher work now... as that _much_ more fun than the ap-test and related parts :)
[15:00] <mzanetti> ok
[15:01] <MacSlow> mzanetti, btw... QV4_ENABLE_JIT_CACHE really has to be unset... just assigning 0 can still keep the QML-cache bug happen again
[15:03] <MacSlow> mzanetti, just wiping ~/.cache/QML before the ap-test-run isn't enough, because the shell-rotation AP-test is using scenarios now - upon QA-team request - thus on ap-test-run causes multiple unity8 start/stop cycles which in turn recreate the qml-cache if $QV4_ENABLE_JIT_CACHE is defined
[15:04] <mzanetti> MacSlow, so does that mean if we land it, our jenkins runs will fail?
[15:04] <MacSlow> mzanetti, no... it can
[15:05] <MacSlow> mzanetti, the failure-rate due to the qml-cache bug is... about 20%
[15:05] <mzanetti> so yes, our jenkins runs will fail then
[15:05] <MacSlow> mzanetti, iirc we have a bug files for this too...
[15:05] <MacSlow> filed
[15:05] <pstolowski> mzanetti, i'm not sure about willy; i'm definately planning to land in vivid as wel
[15:05] <pstolowski> l
[15:06] <pstolowski> mzanetti, i assume willy is kind of required, then we need another silo for vivid overlay
[15:06] <mzanetti> willy :D
[15:07] <pstolowski> gosh ;)
[15:07] <davmor2> hahaha
[15:07] <mzanetti> pstolowski, if that's supposed to to go into vivid, then I think you should just target vivid in the spreadsheet
[15:07] <pstolowski> mzanetti, sure, but we need to target both, no?
[15:08] <MacSlow> pstolowski, mzanetti: what a difference a 'l' can make :)
[15:08] <mzanetti> pstolowski, and that's where I'm a bit lost too tbh
[15:09] <mzanetti> pstolowski, so I guess the only way out would be to branch vivd+overlay in the repos, land to wily and backport to the other...
[15:09] <mzanetti> which is a pain
[15:09] <mzanetti> but anything else is just pointless in one way or the other
[15:10] <tsdgeos> mzanetti: ok, i can actually reproduce it, it's just more subtle that i expected
[15:10] <mzanetti> tsdgeos, I have a feeling after your first fix it's less visible, yes
[15:12] <pstolowski> mzanetti, ok, i got some clarity about click scope part of it at least; it has 15.04 branch which I need to target for "vivid"; trunk is for W
[15:12] <mzanetti> aha!
[15:12] <mzanetti> yeah, that's what I meant with the backporting thing
[15:12] <mzanetti> it's really the only thing that works
[15:13] <mzanetti> we don't have a 15.04 branch in unity though... I suppose I should just create it then
[15:14] <pstolowski> mzanetti, yes... i can small a lot of fun
[15:14] <greyback> pstolowski: "small" "willy" - what fun typos are you making ;)
[15:14] <pstolowski> mzanetti, i've changed the spreadhseet to target vivid
[15:14] <mzanetti> ok, cool
[15:14] <pstolowski> greyback, :)
[15:58] <tsdgeos> mzanetti: ok, found out the problem
[15:58] <tsdgeos> i'm not taking into account the various margins around the journal when calculating what is really seen
[15:58] <tsdgeos> so if we were clipping it'd be right, btu since we're not need to take them into account
[15:59] <mzanetti> aha
[15:59] <tsdgeos> will fix tomorrow
[16:00]  * tsdgeos waves
[16:40] <mzanetti> my laptop battery only charges up to 76% any more :'(