[08:06] <tsdgeos> Saviq: no release? :/
[08:06] <Saviq> tsdgeos, your action branch conflicted and then I couldn't get anyone to reconfigure :|
[08:06] <Saviq> when I resubmitted as ~unity-team
[08:07] <Saviq> so yeah, that's pretty crap
[08:08] <tsdgeos> sorry :/
[08:08] <tsdgeos> what it conflicted with?
[08:08] <Saviq> tsdgeos, audioPlayer
[08:08] <tsdgeos> really?
[08:08] <tsdgeos> damn
[08:09] <Saviq> tsdgeos, yeah, /// vs. //! apparently
[08:09] <tsdgeos> :/
[08:10] <Saviq> tsdgeos, but don't be sorry, that's what this system causes
[08:10] <Saviq> tsdgeos, that would be an advantage of the staging branch
[08:11] <tsdgeos> yeah
[08:11] <tsdgeos> why did we decide against it?
[08:11] <Saviq> more work than worth it
[08:12] <Saviq> tsdgeos, a solution would probably be to start pushing as ~unity-team instead
[08:12] <Saviq> tsdgeos, or well, not require a special person to be able to push a button...
[08:14] <tsdgeos> Saviq: well, pushing as ~unity-team doesn't solve much since it still needs someone to approve your branch, no?
[08:14] <tsdgeos> s/branch/change
[08:15] <Saviq> tsdgeos, no, 'cause there's no change in the CI train system
[08:15] <Saviq> tsdgeos, you just build again
[08:15] <Saviq> tsdgeos, reconfiguration is only needed when MPs change
[08:15] <Saviq> as in MP URL
[08:17] <tsdgeos> oki
[08:21] <Saviq> tsdgeos, could you review https://code.launchpad.net/~unity-team/unity8/unity8-card-overlay/+merge/204790 please?
[08:22] <tsdgeos> sure
[08:22] <tsdgeos> about the build thing
[08:22] <tsdgeos> so what do we do?
[08:22] <tsdgeos> do i remerge my thing?
[08:22] <tsdgeos> approve yours?
[08:22] <tsdgeos> or?
[08:23] <tsdgeos> did you resubmit all the dependant branches on mine to depend on the new one?
[08:23] <Saviq> tsdgeos, I approved mine already, we just need to get someone to reconfigure the silo
[08:23] <Saviq> tsdgeos, let me see if any dependant branches conflict
[08:24] <Saviq> there's only one
[08:32] <tsdgeos> ok
[08:32] <tsdgeos> Saviq: do we need to resubmit it for the prerequisite branch to be updated, or that's old stuff we don't need anymore in this silo approach?
[08:32] <Saviq> tsdgeos, yeah, just did
[08:32] <Saviq> tsdgeos, prerequisite still helps to show the diff correctly
[08:33] <tsdgeos> ok
[08:33] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/new-preview/+merge/205297
[08:33] <Saviq> tsdgeos, so while it's not required, it's useful still
[08:34] <tsdgeos> ok
[08:36] <tsdgeos> done
[08:40] <Saviq> how THE FUCK is that a conflict http://pastebin.ubuntu.com/6890078/
[08:41] <tsdgeos> criss cross
[08:41] <tsdgeos> merge with a different algorithm
[08:41] <tsdgeos> that's what we get for moving stuff around and merging it in weird orders
[08:41] <tsdgeos> it's a bit of sad
[08:42] <tsdgeos> but as said, without staging it's what we are doomed with :D
[08:42] <Saviq> yeah, problem is, will the train try --weave
[08:42] <tsdgeos> i guess that's a question for didrocks
[08:42] <Saviq> tsdgeos, your branch would probably merge with --weave fine, too
[08:43] <Saviq> /have merged
[08:43] <Saviq> oh maybe not
[08:43] <Saviq> there was an actual conflict there
[08:44] <Saviq> tsdgeos, anyway, I think staging is just more work, in the normal case we'd land every day, maybe two
[08:44] <Saviq> tsdgeos, and also I'd need a `pull` instead of `merge` there, I can't live with a history of "pull from staging"
[08:45] <tsdgeos> he he
[08:45] <tsdgeos> sure
[08:45] <tsdgeos> we just need to land every day :D
[08:45] <Saviq> tsdgeos, and we'd have to merge stuff manually into staging, keeping authors and commit messages... bleh
[08:45] <Saviq> tsdgeos, TBH what we really need is more control, and less waiting for didrocks to WAKE UP! ;P
[08:46] <tsdgeos> or that
[08:50] <tsdgeos> Saviq: readonly property var headerHeight: card.headerHeight ?
[08:50] <tsdgeos> why not an alias?
[08:50] <Saviq> tsdgeos, good question
[08:52] <Saviq> tsdgeos, fixed
[08:54] <tsdgeos> hmmmm
[08:54] <tsdgeos> otoh an alias is not readonly
[08:55] <tsdgeos> Saviq: can you also make it readonly? :D
[08:58] <Saviq> tsdgeos, I did
[08:58] <Saviq> tsdgeos, "upstream"
[08:59] <tsdgeos> ¿?
[08:59] <Saviq> tsdgeos, it's readonly in Card.qml
[08:59] <tsdgeos> ah
[08:59] <Saviq> tsdgeos, so if it's an alias in CardTool.qml, it's readonly there, too
[08:59] <tsdgeos> makes sense
[08:59] <tsdgeos> Saviq: shoudl that "gray" be Theme.palette.selected.backgroundText ?
[08:59] <Saviq> tsdgeos, maybe it makes sense to mark it readonly there, too, for doc purposes
[09:01] <Saviq> tsdgeos, did that ↑
[09:01] <Saviq> tsdgeos, if you branched, pull --overwrite
[09:02] <Saviq> tsdgeos, fixed color
[09:02] <tsdgeos> oki
[09:02] <Mirv> Saviq: hi. still row 42 reconfiguring needed I guess?
[09:03] <Saviq> Mirv, indeed :|
[09:03] <Mirv> Saviq: we had a team dinner so obviously no-one was looking at irc even from hotel room
[09:03] <Mirv> ok, doing
[09:03] <Saviq> Mirv, there's one more issue... we have a criss-cross there, do you know if it will try --weave?
[09:03] <tsdgeos> Saviq: no way to show the overlay in testXYZ or at least tryXYZ?
[09:04] <Saviq> tsdgeos, let me add
[09:05] <Mirv> Saviq: we'll find soon enough http://162.213.34.102/job/prepare-silo/73/console
[09:05] <Saviq> tsdgeos, pushed
[09:05] <Saviq> Mirv, thanks
[09:05] <Mirv> Saviq: I don't see 'weave' in the sources at least
[09:06] <Saviq> Mirv, do you know what to do with the branches to fix it?
[09:06] <Saviq> ok let's see (/me doesn't have high hopes ;( http://162.213.34.102/job/landing-004-1-build/11/console)
[09:07] <Mirv> Saviq: not offhand, but let's see and we should have didrocks woken up soon hopefully (7 minutes late! :)
[09:08] <Saviq> !!
[09:11] <Saviq> tsdgeos, added a test case, too
[09:11] <Saviq> tsdgeos, sorry for this not being really-ready ;)
[09:11] <Mirv> Saviq: darn
[09:12] <Saviq> Mirv, yeah :|
[09:12] <Mirv> Saviq: so I guess it does bzr merge after another, in the order of branches, so that should be tweaked to succeed
[09:12] <Mirv> Saviq: or, we'd need a feature to use '--weave'
[09:12] <Saviq> Mirv, the last branch has the second-to-last as prerequisite, so the order can't be changed there
[09:13] <Saviq> Mirv, so yeah, we need --weave (maybe with a job param, but yeah...)
[09:14] <Saviq> if only we could have rebase...
[09:16] <Mirv> didrocks: http://pastebin.ubuntu.com/6890228/
[09:20] <didrocks> Saviq: I think we don't wait weave merge for every merge though, right?
[09:22] <didrocks> "Bazaar no longer uses weaves by default, because they were found to have poor performance and could not provide append-only guarantees."
[09:22] <didrocks> so, not sure we want that for everything
[09:23] <didrocks> and if we add an option to build, it will be for every merges in the set
[09:23] <Saviq> didrocks, oh no, but maybe if a merge fails, it will try remerge with --weave?
[09:23] <didrocks> Saviq: do you think it will be something that everyone would wait?
[09:23] <didrocks> like first merge
[09:23] <didrocks> if fail, -> merge --weave?
[09:23] <Saviq> didrocks, yeah, I think option would be good enough
[09:24] <Saviq> didrocks, with a clear message in the log or so
[09:24] <Saviq> didrocks, and maybe only if criss-cross is detected (if possible)
[09:25] <didrocks> hum
[09:25] <didrocks> not sure if I can get some easy info about criss-cross
[09:25] <didrocks> Saviq: do you have the branches so that I can play and see?
[09:26] <didrocks> Saviq: meanwhile, I think you will have to rebase, if possible :/
[09:26]  * sil2100 looks into that in source
[09:27] <Saviq> didrocks, row 42 in CI train
[09:27] <Saviq> didrocks, the last two I think
[09:27]  * Saviq checks
[09:28] <Saviq> didrocks, rebase... not like that's something easy in bzr :/
[09:29] <didrocks> Saviq: you have a plugin
[09:29] <Saviq> didrocks, discontinued and unsupported... never had any luck with it...
[09:29] <didrocks> oh, worked pretty good for me
[09:30]  * Saviq tries, then
[09:30]  * Saviq generally doesn't seem to have much luck with bzr... bisect never worked, either...
[09:31]  * didrocks didn't try bisect for a while
[09:33] <Saviq> didrocks, rebase → first commit, full of conflicts, files lost, MAYHEM
[09:35] <seb128> Saviq, you are doing it wrong!
[09:35]  * seb128 hides
[09:35] <Saviq> seb128, probably
[09:35] <seb128> Saviq, sorry, friday, troll day, all that ... happy friday! how are you?
[09:36] <Saviq> seb128, sad atm, can't land since yesterday evening :(
[09:36] <seb128> :-(
[09:36] <Saviq> ok, let's see, something rebased
[09:40] <tsdgeos> Saviq: cool looking overlay!
[09:40] <Saviq> tsdgeos, /me happy
[09:41] <tsdgeos> Saviq: i don't know much/anything about shaders though
[09:41] <tsdgeos> so i'll just assume the shader works because it does work
[09:41] <Saviq> tsdgeos, it's pretty simple - the vertex shader is just the default
[09:41] <Saviq> tsdgeos, i.e. no modification
[09:41] <tsdgeos> and the other multiplies
[09:41] <Saviq> tsdgeos, the other applies the images' opacity on black
[09:41] <tsdgeos> sure i can see that
[09:41] <Saviq> tsdgeos, that it
[09:41] <tsdgeos> i just don't have a clue if it can be made faster/better
[09:42] <Saviq> tsdgeos, ah well
[09:42] <Saviq> tsdgeos, it's temporary anyway
[09:42] <Saviq> hum conflict in tst_Indicators.qml, that's weird
[09:42] <tsdgeos> Saviq: dednick changed lots of stuff in indicators
[09:43] <tsdgeos> maybe it didn't play well together
[09:43] <Saviq> tsdgeos, yeah, but I'm rebasing
[09:43] <tsdgeos> ah
[09:43] <tsdgeos> Saviq: so your card CI didn't succeed
[09:43] <Saviq> tsdgeos, neither branch should be touching it...
[09:43] <tsdgeos> but it's obviously not related to your change
[09:43] <Saviq> tsdgeos, autopilot?
[09:43] <tsdgeos> checklist-approve anyway
[09:43] <tsdgeos> yeah
[09:45] <Saviq> http://pastebin.ubuntu.com/6890343/
[09:45] <Saviq> WTF
[09:46] <dednick> weird. spacing?
[09:46] <dednick> on end.?
[09:48] <Saviq> dednick, no, whitespace would've complained
[09:49] <Saviq> anyway, no, that rebase isn't happening
[09:59]  * Saviq went for manual rebase
[09:59]  * Saviq crosses fingers http://162.213.34.102/job/landing-004-1-build/12/console
[09:59]  * sil2100 crosses fingers as well
[10:05] <Saviq> \o/
[10:05] <tsdgeos> \o/
[10:05] <Saviq> in your FACE, bzr
[10:08] <sil2100> HA
[10:08] <sil2100> Saviq: good work!
[10:08] <sil2100> ;)
[10:21] <Saviq> sil2100, Mirv, can you please reconfigure row 42 again? just added one more MP that can land
[10:24] <sil2100> Saviq: ok, will do
[10:29] <sil2100> Saviq: ok, reconfigured, re-build
[10:30] <Saviq> sil2100, thanks!
[10:40] <tsdgeos> Saviq: so looking at cardheader <-> previewheader
[10:41] <Saviq> tsdgeos, yup?
[10:41] <tsdgeos> the json specifies emblem and attribute-x
[10:41] <tsdgeos> that cardheader doesn't have ¿yet?
[10:47] <tsdgeos> Saviq: so ignore those attribs for the moment? or?
[10:48] <Saviq> tsdgeos, yeah
[10:48] <tsdgeos> okidoki
[11:00] <Saviq> karni, hey, rebased title alignment on trunk, but I believe it's reversed: https://code.launchpad.net/~unity-team/unity8/header-alignment/+merge/205334
[11:01] <Saviq> karni, it should always be Left-aligned in horizontal, sometimes center-aligned in vertical, no?
[11:09]  * tsdgeos kicks launchpad
[11:09] <tsdgeos> so https://code.launchpad.net/~saviq/unity8/new-preview tells me there's 1 branch that depends on that one
[11:09] <tsdgeos> but then the link says none
[11:09] <tsdgeos> aaaaaaaa
[11:09] <tsdgeos> Saviq: do you know what comes after that one?
[11:11] <Saviq> tsdgeos, card-overlay, no?
[11:11] <Saviq> hmm no
[11:14] <Mirv> Saviq: ok, looks positive you'll have a landing PPA to run tests from soonish? built for armhf now :)
[11:16] <Saviq> Mirv, yeah
[11:30]  * Saviq TestPlans
[11:49] <sil2100> jamesh: hello!
[11:49] <sil2100> jamesh: are you around? I have some problems with the new mediascanner
[12:06] <tsdgeos> Saviq: cardheader doesn't define width nor implicitwidth, that ok?
[12:10] <sil2100> mhr3: hi!
[12:10] <mhr3> sil2100, hey
[12:10] <sil2100> mhr3: you in the office today?
[12:10] <mhr3> sil2100, on my way there
[12:10] <mhr3> sil2100, btw did you see my libunity landing request?
[12:10] <sil2100> mhr3: I'll snatch you once you appear, since I see jamesh seems to be away, and I don't see Satoris as well
[12:11] <mhr3> sil2100, satoris in on #canonical
[12:11] <sil2100> mhr3: poke robru for that today - he's doing most landings now as part of practicing ;)
[12:11] <sil2100> mhr3: oh, ok, I'll poke him there as well, but you'll be poked as well
[12:11] <sil2100> In person
[12:12] <sil2100> Since we have a big regression related to mediascanner
[12:12] <sil2100> And its scope
[12:12] <mhr3> sil2100, hmm?
[12:12] <mhr3> sil2100, i was testing that yesterday it seemed fine
[12:13] <mhr3> sil2100, anyway, will be there in ~30
[12:13] <sil2100> mhr3: yeah, so... it's something that's happening only on newest images, since after the release of unity-scopes-mediascanner and mediascanner2 the grilo plugin for mediascanner got dropped
[12:13] <sil2100> mhr3: so, basically the music-app stopped working
[12:13] <sil2100> mhr3: like, completely
[12:14] <mhr3> sil2100, it shouldn't have been dropped if music-app deps on it
[12:14] <sil2100> mhr3: also, I noticed a packaging problem I guess
[12:14] <mhr3> sil2100, but the scopes dont
[12:14] <sil2100> mhr3: I don't think it does, it's a click app and I'm not really into how click apps deal with deps
[12:14] <mhr3> they don't afaik
[12:15] <sil2100> mhr3: yeah, so basically the scopes dropped the dependency and now we don't have grilo anymore
[12:15] <sil2100> mhr3: it's not being used in either the new and old mediascanner scope?
[12:15] <sil2100> (like, at all?)
[12:15] <mhr3> sil2100, no, the scopes (both old and new) use mediascanner2
[12:16] <mhr3> that doesn't do grilo
[12:16] <sil2100> mhr3: ok, but we still need the old mediascanner for music-app then, right? Those two can still run in parallel?
[12:16] <mhr3> sil2100, yes
[12:17] <mhr3> sil2100, but music-app will also transition to mediascanner2 at some point
[12:17] <mhr3> then we'll drop the whole mediascanner1 + grilo
[12:17] <sil2100> mhr3: ok then, so I guess we can either add grilo-mediascanner to the seed to fix it, or simply add a quick dependency to mediascanner to fetch grilo-mediascanner
[12:17] <sil2100> mhr3: right, but for now we need to fix the image ;)
[12:17] <sil2100> mhr3: but thanks for the info
[12:24] <sil2100> mhr3: ok, so we decided to seed the grilo plugin in the meantime, so it's being done ;)
[12:24] <sil2100> mhr3: so no action required from you, thanks for clearing things up
[12:25] <tsdgeos> Cimi: Saviq: this one shall be easy https://code.launchpad.net/~aacid/unity8/preview_header/+merge/205354
[12:25] <mhr3> sil2100, good decision :)
[12:29] <Cimi> tsdgeos, one extra new line on tests, after imports :)
[12:29] <tsdgeos> and probably too many imports
[12:30] <Cimi> tsdgeos, tests could have something more maybe?
[12:30] <Cimi> but card header is already tested though
[12:31] <tsdgeos> Cimi: yeah the only thing i am testing is my code
[12:38] <tsdgeos> Cimi: fixed
[12:59] <Saviq> tsdgeos, it should implicitHeight, yes
[12:59] <Saviq> tsdgeos, the widget, that is, yeah - what you did
[13:00] <Saviq> tsdgeos, header itself has explicit height
[13:00] <mhr3> sil2100, if you still need, i'm here
[13:00] <Saviq> tsdgeos, 127	+ function test_something() { a better name maybe?
[13:09] <Saviq> tsdgeos, actually, it should be explicit height for the widget, too, no? i.e. the header doesn't really adapt when its height is changed
[13:33] <karni> o/
[13:52] <karni> Saviq: am I sleepy, or tryCardTool shows 11 cases in the drop down, while source contians 15 cases for that dropdown.
[13:52] <Saviq> karni, there's a gazillion of branches, which one? ;)
[13:53] <karni> Saviq: sorry, the one you rebased https://code.launchpad.net/~unity-team/unity8/header-alignment/+merge/205334
[13:53] <karni> I fixed what you suggested (yeah.. that indeed was reversed) and wanted to inspect that visually as well
[13:53] <Saviq> karni, just swipe ;)
[13:55] <karni> NACK. First one for me is "art, header, summary", last one is "art, header - portrait"
[13:55] <karni> I can see the full list from top to bottom
[13:55] <karni> FTR my network is a bit laggy
[13:57] <karni> let me rebuild this
[13:57] <karni> I think that's my problem
[13:57] <karni> Saviq: ignore me for now.
[13:57] <Saviq> karni, ;)
[14:00] <karni> tsdgeos: if you'd review this related branch as well, we'd have slick overlay both in trunk and new-scopes https://code.launchpad.net/~unity-team/unity8/newscopes-card-overlay/+merge/205359
[14:00]  * karni sets description
[14:02] <karni> done
[14:08] <tsdgeos> Saviq: fixed
[14:09] <Saviq> tsdgeos, cheers
[14:14] <Cimi> Saviq, I'm writing the style for rating component, and I realised styleItem works even if I don't import Ubuntu.Components in the delegate file... why?
[14:15] <Saviq> Cimi, it's probably the one from external scope
[14:15] <Saviq> if your whole chain of parents won't have Ubuntu.Components, it won't be there
[14:17] <tsdgeos> wooo, my hud-service went crazy
[14:17]  * tsdgeos kills it
[14:17] <tsdgeos> better
[14:18] <pete-woods> tsdgeos: can you reproduce that?
[14:18] <pete-woods> tsdgeos: I am desperate to find a way
[14:18] <tsdgeos> first time it happens
[14:18] <pete-woods> I've a report that sublimetext can send the new HUD into an infinite loop
[14:19] <tsdgeos> not using that
[14:19] <tsdgeos> i was using firefox, kate, kontact
[14:19] <tsdgeos> the same stuff i have open all the time
[14:19] <mhr3> mhall119, you forgot about me :(
[14:20] <pete-woods> okay, thanks, I'll try running those
[14:20] <tsdgeos> but had never had this 100% before
[14:20] <tsdgeos> so it must not be because of them
[14:20] <tsdgeos> i notice when the laptop fan spins :D
[14:20] <pete-woods> okay, fair point, but still :)
[14:20] <mhall119> mhr3: I could never forget you
[14:21] <tsdgeos> pete-woods: anything you want me to do if it happens a next time?
[14:21] <mhall119> (where/how did I forget you?)
[14:21] <mhr3> mhall119, no new scopes docs
[14:21] <mhall119> oh, right, docs
[14:22] <mhall119> mhr3: I'm going to blame the hotel wifi and claim that I didn't forget :)
[14:22] <pete-woods> tsdgeos: if you could try and get a stacktrace out of it, that would be very helpful
[14:22] <mhr3> mhall119, and i'll *almost* believe you
[14:22] <tsdgeos> pete-woods: ok, will do if it happens again, sorry to have been to trigger fast killing it
[14:22] <pete-woods> tsdgeos: no worries
[14:23] <pete-woods> even better would be a reproducable way to cause the loop
[14:23] <pete-woods> :)
[14:23] <pete-woods> I realise that would be making my job far too easy, though
[14:23] <mhr3> mhall119, if you said that the sun in florida melted your enter, that would be more believable :)
[14:23] <tsdgeos> karni: i'm a bit confused about that MR
[14:23] <tsdgeos> it wants to merge to lp:~unity-team/unity8/new-scopes but has a branch that wants to merge to lp:unity8 as pre-requisite ¿?
[14:24]  * karni looks
[14:24] <Cimi> Saviq, I started working on the textSummary branch, but I didn't merge there the latest changes of audioPlayer, so when I set textSummary as prerequisite I don't have the right diff on lp https://code.launchpad.net/~cimi/unity8/units8.previews_RatingStars/+merge/205370
[14:25] <karni> tsdgeos: Correct. Saviq helped me out pull as much as we could into trunk, so this change is specific to new-scopes, but does require the other branch to be merged to unity8 trunk first.
[14:25] <karni> tsdgeos: These are the new-scopes specific overlay bits.
[14:26] <mhall119> mhr3: uploading now...
[14:26] <tsdgeos> karni: i don't understand how does it matter what is in unity8 since new-scopes is a different branch
[14:27] <mhr3> mhall119, thx
[14:27] <karni> tsdgeos: in my understanding new-scopes is unity8 with only set of changes required to enable new scopes UI/toolkit.
[14:27] <tsdgeos> yes
[14:27] <karni> tsdgeos: when we work on dash toolkit, we do as much as we can in trunk, and as little as we can in new scopes
[14:28] <tsdgeos> ok, maybe it's different understanding of "prerequiste" branches
[14:28] <karni> because trunk does not contain CardFilterGrid and CardCarousel
[14:28] <tsdgeos> for me a prerequisite is "something that you need landed before you land this one"
[14:28] <karni> tsdgeos: I still believe the other merge to trunk is required for this merge to go smooth.
[14:28]  * karni looks
[14:28] <tsdgeos> ok
[14:29] <karni> tsdgeos: give me a sec please
[14:29] <tsdgeos> sure
[14:30] <mhall119> mhr3: check the docs and let me know if your new stuff is there
[14:30] <mhall119> mhr3: it would be nice if you could write a parser for your docs to push them to the new API website on your own
[14:30] <mhr3> mhall119, yep, it is, thx
[14:31] <mhr3> mhall119, i might get to that... in 2015
[14:31] <mhall119> :-P
[14:31] <mhall119> but it's easy
[14:32] <mhall119> I even made a nice python library for you
[14:32] <mhall119> s/nice/functional/
[14:32] <mhr3> can't it be both? :)
[14:34] <karni> tsdgeos: unity8-card-overlay (being merged to unity8 trunk) defines property bool showHeader in qml/Dash/Card.qml, which is then used in new-scopes. My bad, please don't review the other branch now. We'll first get the trunk one merged, we'll merge changes from trunk to new-scopes, and only then we'll approve the MR I sent over into new-scopes.
[14:34] <karni> tsdgeos: Now I understand the flow Saviq usually executes when there are related changes to trunk and new-scopes.
[14:35] <tsdgeos> oki
[14:35] <karni> first merge to trunk, then merge trunk to new-scopes, only then approve and merge related branches into new-scopes
[14:35] <karni> tsdgeos: unless, you want to review it, but not top-approve it yet. that'd be the same thing, basically.
[14:35] <mhall119> mhr3: it can be, if it was written by somebody with more talent than me :)
[14:35] <karni> You're fresh on the subject, as you just reviewed the trunk one
[14:36] <mhall119> mhr3: I just have a bad habit of re-inventing Django's model objects for any given python project
[14:37] <mhall119> but in this case it makes sense, because it's talking directly with Django models on the server-side
[14:40] <tvoss> mzanetti, ping
[14:40] <mzanetti> tvoss: hi
[14:42] <elopio> ping mterry: I have the test passing, without depending on the calendar
[14:43] <mterry> elopio, calendar?
[14:43] <elopio> sorry, still early. s/calendar/camera
[14:43] <elopio> I'm wondering if we want this test in unity8, because to make it work we need the real application manager.
[14:48] <karni> Saviq: pushed fix to https://code.launchpad.net/~unity-team/unity8/header-alignment/+merge/205334 . All tests pass, but the problem appears when you switch card layouts more than once in testCardTool. "Title - horizontal" > "Title - vertical" > "Title - horizontal" boom Card height undefine., no card displayed.
[14:54] <tsdgeos> oh god
[14:54] <tsdgeos> someone did add the automagically creating setters and getters for QPROPERTIES
[14:54] <tsdgeos> \o/
[14:54] <tsdgeos> at last :D
[14:55] <karni> wohoo
[14:56] <tsdgeos> https://plus.google.com/117221897452321521192/posts/hZQDDnwduhs
[14:57] <Cimi> tsdgeos, help with rating widget? from the json, I don't understand which are the data I get
[14:58] <tsdgeos> let me see
[14:59] <mzanetti> tsdgeos: nice" that is awesome!
[14:59] <tsdgeos> Cimi: which one are you doing? "rating-input" ?
[15:00] <Cimi> tsdgeos, I currently just worked on the rating widget under COmponents
[15:00] <MacSlow> greyback, hey... can you make it to the hangout?
[15:01] <Saviq> elopio, hey, do you have a maguro?
[15:01] <tsdgeos> Cimi: ok, so i didn't understand your question :D
[15:01] <elopio> Saviq: I don't.
[15:02] <elopio> but I know people. What do you need?
[15:02] <tsdgeos> mhr3: ping?
[15:02] <mhr3> tsdgeos, sup
[15:02] <Saviq> elopio, http://ci.ubuntu.com/smokeng/ we're getting some apparently random ap failures on maguro
[15:02] <tsdgeos> mhr3: so how do we do progress reporting for "type": "progress" ?
[15:02] <Cimi> tsdgeos, but I was expecting a rating bar
[15:02] <Cimi> tsdgeos, not input and review
[15:03] <mhr3> tsdgeos, there's some progress provider thing
[15:03] <Cimi> tsdgeos, it looks like we're missing that widget in the spec
[15:03] <tsdgeos> Cimi: the rating bar is part of the header i think
[15:03] <Cimi> tsdgeos, scope like IMDB won't feature single reviews
[15:03] <mhr3> tsdgeos, it's used by the app preview
[15:03] <mhr3> tsdgeos, the old one
[15:03] <elopio> Saviq: robotfuel and davmor2 have maguros. Any of you have some time to try to reproduce them?
[15:03] <Saviq> elopio, one of them was in the emulators tests, another in hud, will have to check it out then
[15:03] <Saviq> elopio, davmor2 was already looking into it
[15:04] <davmor2> elopio: tests are rerunning now :)
[15:04] <robotfuel> Saviq: elopio can try to reproduce on a maguro, if you need me to
[15:05] <tsdgeos> mhr3: com.canonical.applications.Downloader ?
[15:05] <elopio> Saviq: yeah, I saw the error they mentioned on the open scope test I added. Without a maguro or a video of the run, it's really hard to understand what's going on. The log says autopilot tried the drag correctly.
[15:05] <Saviq> elopio, indeed
[15:05] <tsdgeos> mhr3: but that's too specific, no?
[15:05] <mhr3> tsdgeos, yea, that thing
[15:05] <elopio> robotfuel: thanks, but it seems davmor2 is way ahead.
[15:06] <robotfuel> ack :D
[15:06] <mhr3> tsdgeos, we didn't really define much what's the data for that widget
[15:06] <mhr3> tsdgeos, see....
[15:06] <tsdgeos> mhr3: i know, but if we need to code it ... :D
[15:06] <mhr3> tsdgeos, http://people.canonical.com/~mhr3/unity-scopes-api/classunity_1_1scopes_1_1_preview_widget.html#progress
[15:06] <tsdgeos> mhr3: maybe that name should come as part of the json too?
[15:08] <tsdgeos> mhr3: i can't edit the json document, so it would be "source": ["dbus-name" : "somename", "dbus-object": "somestring" ]; instead of "source": null , yes?
[15:11] <Cimi> tsdgeos, ?
[15:11] <Saviq> karni, mhr3, tsdgeos, merged everything into lp:unity-team/unity8/new-scopes
[15:11] <Saviq> karni, tsdgeos, so reviews of https://code.launchpad.net/~unity-team/unity8/new-scopes/+activereviews can be done again
[15:11] <tsdgeos> Cimi: which ratings are you speaking about?
[15:12] <tsdgeos> Cimi: i.e. do you have a design so we can we sure we're speaking about the same thing :D
[15:12] <karni> ack
[15:13]  * karni tries to reproduce with a test the problem in tryCardTool in header-alignment branch
[15:14] <karni> Ironically, when using tryCardTool, problem is obvious, but from the test (by setting the drop down selector) test passes, when it should fail.
[15:20] <Cimi> tsdgeos, get my branch
[15:20] <Cimi> tsdgeos, well, I have design in mind
[15:20] <Cimi> didn't check specs
[15:21] <Cimi> ah I see
[15:21] <Cimi> basically rate this
[15:21] <Cimi> tsdgeos, Saviq putting just an icon of a star with a label (4.9) means nothing
[15:22] <Cimi> in the header
[15:22] <Cimi> you need a visual clue of the range
[15:22] <Cimi> otherwise you put %
[15:22] <karni> Saviq: FTR whenever you have a moment - can't make this use case fail from code, left a comment on branch. clearly it fails when run manually on tryCardTool https://code.launchpad.net/~unity-team/unity8/header-alignment/+merge/205334
[15:22] <tsdgeos> Cimi: talk to design :)
[15:22] <Cimi> so the range is per cent
[15:22] <Cimi> tsdgeos, we need to add 5 if we want to turn 4.9 meaningful
[15:22] <Cimi> so 4.9 / 5
[15:23] <Cimi> 4.9 could be super crap if it's out of 10 or great if itos out of 5
[15:23] <mhr3> tsdgeos, well, it really depends on the progress indicator, i guess the only one ew have now is dbus-based, but basically we were saying in the spec that we don't care, whatever the progress provider requires should be there
[15:24] <mhr3> tsdgeos, s/indicator/provider/
[15:25] <tsdgeos> mhr3: not sure i understand you, you mean that you don't want to spec the dbus names?
[15:26] <mhr3> tsdgeos, we should support multiple types of progress indication, the dbus-based is just one of them
[15:27] <mhr3> tsdgeos, although the only one atm
[15:27] <tsdgeos> mhr3: ok, but still we should spec them all, no?
[15:28] <mhr3> tsdgeos, right, the thing is that what they need can change independently of scopes or the shell
[15:28] <tsdgeos> mhr3: so how is the shell going to automagically adapt?
[15:29] <mhr3> tsdgeos, what's why the spec says "whatever the provider needs"
[15:29] <tsdgeos> i mean eventually
[15:30] <tsdgeos> we need to do code to do stuff
[15:30] <tsdgeos> if that code has unknown input
[15:30] <tsdgeos> that's kind of hard to achieve
[15:34] <Cimi> tsdgeos, but even then
[15:35] <Cimi> tsdgeos, the json how is supposed to set the value?
[15:35] <tsdgeos> Cimi: can you show me the design we're talking about?
[15:36] <Cimi> tsdgeos, https://docs.google.com/a/canonical.com/document/d/1n880Fih5KyGPcoP5chidnHDG_8TxXUgSuij7f4rHpuk/edit#heading=h.c86ldo7kh1u
[15:36] <Cimi> https://docs.google.com/a/canonical.com/document/d/1NmiM4UCnJgf6IEawmfyTOHRNAA5ZGrqpyrPqPOibwc8/edit
[15:36] <tsdgeos> Cimi: so the header?
[15:36] <Cimi> tsdgeos, no, rating input
[15:37] <tsdgeos> it's input
[15:37] <tsdgeos> you don't get anything
[15:37] <tsdgeos> you set it
[15:37] <tsdgeos> no?
[15:37] <Cimi> tsdgeos, ok, but then this widget needs a way to set the new input, no?
[15:37] <tsdgeos> Cimi: the triggered signal with some stuff in the data variable
[15:37] <tsdgeos> i'd say
[15:40] <Cimi> tsdgeos, so I have to add a signal?
[15:41] <Cimi> tsdgeos, currently, rating has no signal, just you use the property value
[15:46] <tsdgeos> Cimi: previewidget has a signal
[16:04] <karni> Saviq: If you have something I could bite today, feel free to hit me. Previews are the last bit we care about, and it's my last day at the sprint, so whatever you have, happy to join effort.
[16:05] <Saviq> karni, lp:~saviq/unity8/newscopes-new-dash-look
[16:05] <Saviq> karni, run it in actual unity (not the dev tool)
[16:05]  * Saviq pushes to ~unity-team
[16:06] <elopio> mterry, Saviq, mzanetti: so what do you think about https://code.launchpad.net/~elopio/unity8/url-dispatcher_test/+merge/205037 ?
[16:06] <elopio> should we merge it even if it uses the real unity-mir ?
[16:07] <Saviq> elopio, IMO ap tests are integration tests, so they should use the real thing, so I'm good - but obviously you need to disable it for desktop scenarios
[16:08] <Cimi> tsdgeos, which signal?
[16:08] <tsdgeos> Cimi: see the actionpreviewwidget branch
[16:08] <tsdgeos> we need to land all that crap :D
[16:09] <mhr3> Saviq, we seem to have lost the new-scopes preview integration branch
[16:09] <mhr3> any idea where did it go?
[16:09] <karni> Saviq: ack
[16:10] <tsdgeos> Cimi: this signal https://code.launchpad.net/~unity-team/unity8/action_preview_widget/+merge/205232
[16:10] <tsdgeos> mhr3: https://code.launchpad.net/~unity-team/unity8/newscopes-preview/+merge/205029 ?
[16:10] <Cimi> tsdgeos, just land those!
[16:10] <elopio> Saviq: ok. It's disabled for desktop.
[16:10] <Cimi> we have deps of deps
[16:11] <tsdgeos> Cimi: well if our tests weren't that unstable, that'd be done ages ago
[16:11] <mterry> elopio, your test got fancy!
[16:11] <mterry> elopio, real unity-mir is better, yeah
[16:11] <Saviq> mhr3, huh https://code.launchpad.net/~unity-team/unity8/newscopes-preview/+merge/205029 ?
[16:12] <Saviq> mhr3, but it'll be in new-scopes itself soon
[16:12] <Saviq> mhr3, and in demo-stuff, then
[16:16] <mhr3> Saviq, ah, wip, that's why i didn't see it
[16:16] <mhr3> how come https://code.launchpad.net/unity8 doesn't list it?
[16:17] <mhr3> right... because i'm blind
[16:17] <elopio> mterry: and just wait for the python-fixtures to start landing in ubuntu-ui-toolkit, it's going to shine :)
[16:17] <mterry> :)
[16:19] <karni> brb reboot
[16:28] <karni> Saviq: run that branch  with ./run ?
[16:28] <karni> Is that what you meant?
[16:28] <Saviq> karni, yes
[16:29] <Saviq> karni, we need to change text colours
[16:29] <karni> Saviq: I did. fonts are white on light background
[16:29] <Saviq> karni, yeah, that's what needs fixing
[16:29] <karni> wait, I'm sure it was fixed somewhere already
[16:29] <karni> I did see it look right before, with the light background.
[16:29] <karni> on it
[16:30] <tsdgeos> elopio: is _open_scope_scrolling yours?
[16:30] <tsdgeos> in dash.py?
[16:31] <elopio> tsdgeos: and yours ;)
[16:31] <tsdgeos> sure
[16:31] <tsdgeos> elopio: there's a bug
[16:31] <tsdgeos> moving doesn't do what you think it does
[16:31] <tsdgeos> and that is why https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2656/testReport/junit/unity8.shell.tests.test_emulators/DashAppsEmulatorTestCase/test_get_details_Desktop_Nexus_10_/ fails sometimes
[16:31] <elopio> interesting.
[16:31] <tsdgeos> moving is "vertically moving", not horizontally moving
[16:31] <karni> wtf.. I'm having unity7 rendering issues ://
[16:32] <karni> makes it hard to work
[16:32] <elopio> tsdgeos: is there a horizontally moving?
[16:32] <tsdgeos> elopio: thinking about it
[16:32] <tsdgeos> elopio: we way need to resort to testing the x as we did somewhere
[16:33] <tsdgeos> or let me check
[16:33]  * elopio fires up the vis.
[16:33] <tsdgeos> actually yes
[16:33] <Saviq> tsdgeos, karni, mhr3, newscopes-preview merged into new-scopes, too
[16:34] <karni> \o/
[16:34] <Saviq> so quality of new-scopes just went drastically down
[16:34] <Saviq> but at least everything's in one place
[16:34] <karni> :D
[16:34] <tsdgeos> elopio: what we want is moving but on dashContentList not on the scope
[16:34] <tsdgeos> elopio: since the scope is verticall and dashContentList is the horizontal one
[16:34] <tsdgeos> elopio: am i making sense?
[16:34] <elopio> tsdgeos: you are, yes.
[16:34] <elopio> let me see how can I get that element.
[16:35] <tsdgeos> elopio: do you think you can code that? i think it'll be faster if you do it than if i do, my autopilot+python foo is not very food
[16:35] <tsdgeos> goof
[16:35] <tsdgeos> good
[16:35] <mhr3> Saviq, it enables further dev, so +1
[16:35] <elopio> tsdgeos: yes, I'm trying.
[16:35] <Saviq> mhr3, yeah, why I did it exactly
[16:36] <tsdgeos> elopio: cool
[16:36] <mhr3> Saviq, re-building demo ppa
[16:36] <elopio> tsdgeos: and just for future reference, how can I know if the moving is vertical or horizontal? It's not clear to me as I can move the scope in both directions.
[16:37] <mhr3> thostr_, ^^ previews hooked up soon in demo ppa's unity8 (+scope-tool)
[16:37] <tsdgeos> elopio: let me rephrase
[16:37] <tsdgeos> moving is moving
[16:37] <tsdgeos> amazing skills i have here :D
[16:37] <tsdgeos> elopio: basically the dash is listviews inside listvides
[16:37] <tsdgeos> so there is an external one that is horizontal
[16:37] <tsdgeos> and that external one, contains one listview per scope that is vertical
[16:38] <tsdgeos> so it's not that moving is vertical
[16:38] <mhr3> Saviq, also, i have a branch with addSpecialCategory, wanna try it out?
[16:38] <tsdgeos> is that the moving for the listview you are testing is the vertical listview
[16:38] <tsdgeos> and we have to test the moving for the horizontal one
[16:38] <tsdgeos> elopio: ↑↑↑ making sense?
[16:40] <elopio> tsdgeos: yes yes, I also made a poor question :)
[16:40] <elopio> so, the thing is that I need to wait for the list I'm moving.
[16:40] <elopio> a container might have moving = False even if one of its elements have moving=True.
[16:40] <elopio> that's good to know.
[16:41] <tsdgeos> it could yes
[16:41] <tsdgeos> note that in this case is the other way around
[16:41] <tsdgeos> you're testing for the inner thing and that one is not moving
[16:41] <tsdgeos> what is moving is the outer thing
[16:41] <tsdgeos> well the inner thing is being moved
[16:41] <tsdgeos> but not moving itself
[16:41] <elopio> oh, right.
[16:41] <tsdgeos> the naming is not amazing
[16:42] <tsdgeos> moving == scrolling || overshooting
[16:42] <tsdgeos> that makes it easier to understand i guess
[16:42] <tsdgeos> moving != "travelling around" on your parent
[16:42] <elopio> tsdgeos: it's clear, thanks :)
[16:43] <elopio> it's really bad that we don't have a good way to actually test this. I would need to slow down the animations.
[16:44] <tsdgeos> you could do that
[16:44] <tsdgeos> i guess
[16:44] <tsdgeos> or maybe not
[16:44] <tsdgeos> elopio: yeah it's a problem with these kind of tests
[16:44] <tsdgeos> but if you look at the video of the failure closely
[16:45] <tsdgeos> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2656/artifact/results/autopilot/artifacts/unity8.shell.tests.test_emulators.DashAppsEmulatorTestCase.test_get_details%20%28Desktop%20Nexus%2010%29.ogv
[16:45] <elopio> tsdgeos: where did you get a video from?
[16:45] <tsdgeos> you'll see it's clearly that isue
[16:45] <tsdgeos> issue
[16:45] <elopio> oh, it's failing on trusty too, I thought it was only maguro.
[16:45] <tsdgeos> the mouse moves and tries to click before the moving is done
[16:45] <tsdgeos> and ends up in the wrong place
[16:46] <karni> saldkfjlsadkj why doesn't this list colors http://design.ubuntu.com/apps/style/typography
[16:46] <elopio> davmor2, Saviq ^
[16:47] <karni> I lost the link to Ubuntu Theme colors on d.u.c
[16:47] <elopio> thanks to tsdgeos I now know what to fix.
[16:47] <tsdgeos> elopio: not really sure that one is the same than http://ci.ubuntu.com/smokeng/trusty/touch/maguro/167:20140206.1:20140115.1/6480/unity8-autopilot/741839/
[16:47] <tsdgeos> but may be
[16:48] <tsdgeos> the hud one, sadly, no clue
[16:49] <Saviq> elopio, tsdgeos, thanks, that makes some sense
[16:49] <Saviq> and on that note...
[16:49] <Saviq> or well, bombshell
[16:49] <Saviq> o/
[16:49] <Saviq> be back on the 17th
[16:49] <tsdgeos> enjoy!
[16:50] <tsdgeos> elopio: i'm going to EOD soon, do you have anyone to review that potential patch in your timezone (you're americas based, right?)
[16:50] <elopio> tsdgeos: yes. Lets see... mterry?
[16:50] <mterry> elopio, sure, I can do that today
[16:50] <tsdgeos> that should work
[16:55] <davmor2> elopio: ah nice does that mean you can test fro a fix there and then I can confirm on maguro?
[16:55] <Cimi> tsdgeos, in oreviewactions you imported qtquick 2.1
[16:55] <Cimi> *previewactions
[16:56] <Cimi> tsdgeos, why that?
[16:56] <tsdgeos> Cimi: for no reason really
[16:57] <tsdgeos> i think we should be importing 2.1 everywhere
[16:57] <tsdgeos> Cimi: i could change it to 2.0
[16:57] <tsdgeos> but let's just leave it
[16:57] <elopio> davmor2: more or less, I can't make a proper test atm as I don't know how to keep the list moving.
[16:57] <tsdgeos> or it'll create a massive cris cros again in the merges
[16:58] <karni> tsdgeos: I used "grey" in CardHeader.qml as text color. Saviq changed it to theme color, Theme.palette.selected.backgroundText, which is white. And we have light background in new-scopes. That means, the Theme does not contain a color we can use in stead of "grey".
[16:58] <karni> tsdgeos: Your take on this?
[16:58] <elopio> bad news, this can't be the same maguro problem.
[16:58] <elopio> tsdgeos, davmor2.
[16:59] <karni> tsdgeos: basically, Ubuntu.Components.Themes.Palette would need to be updated for new-scopes.
[17:00] <tsdgeos> elopio: oh :/
[17:00] <tsdgeos> elopio: why not?
[17:00] <tsdgeos> karni: yes, Saviq was hinting that on our mumble chat
[17:00] <elopio> tsdgeos: on the scroll we have self.dash_content_list.currentIndex.wait_for(original_index + 1), and that's what's failing on maguro.
[17:00] <tsdgeos> karni: we may want to choose or tweak the theme
[17:01] <tsdgeos> elopio: ah
[17:01] <tsdgeos> karni: or hardcode some stuff
[17:01] <karni> tsdgeos: shall I make it grey temporarily? fonts are now invisible if you ./run newscopes-new-dash-look
[17:01] <tsdgeos> karni: sure, and add a todo
[17:01] <karni> tsdgeos: I say I put "grey" in there so we see anything, and leave a todo to update the theme
[17:01] <karni> ok
[17:01] <tsdgeos> karni: we'll have a look at it next week need to run now
[17:01] <karni> ok!
[17:01] <tsdgeos> davmor2: can you reproduce the issue? i guess not, right?
[17:02] <elopio> it doesn't even get to the point where we wait for the animation to finish and click something else.
[17:02] <elopio> the problem there seems to be that the drag is actually failing to move to the next one.
[17:02] <tsdgeos> or that there is no next one
[17:02] <tsdgeos> i.e. hasn't loaded yet?
[17:03] <tsdgeos> davmor2: if you can reproduce it'd be good if you can run the test exporting QML_BAD_GUI_RENDER_LOOP=1 just to make sure it's not the awful 5.0 qml scene graph playing tricks on us
[17:04]  * tsdgeos really has to run now
[17:04] <tsdgeos> til morning!
[17:08] <davmor2> tsdgeos: I have run two sets of test let me grab the ouput from that first run got  http://paste.ubuntu.com/6891542/ and  the second got http://paste.ubuntu.com/6891973/
[17:12] <elopio> mterry: https://code.launchpad.net/~elopio/unity8/fix1277591-open_scope_scrolling_waiting_for_wrong_property/+merge/205423
[17:13] <elopio> davmor2: if you could capture a video of what unity is doing when you get that failures, it'd be awesome.
[17:14] <davmor2> elopio: HA!   that will definitely have to wait till Monday
[17:18] <mterry> elopio, grabbing lunch but will review your branches after
[17:20] <elopio> mterry: that's just fine, thanks.
[18:24]  * greyback eow o/
[20:43] <cwayne> hm, my theming is all messed up after updating