[07:35] <Mirv> filed bug #1254986 regarding unity-mir with new Mir
[08:04] <Mirv> but before that the priority #1 is anyhow bug #1253685
[08:18] <tsdgeos> Mirv: why is that critical now? it's just at shutdown, no?
[08:18] <tsdgeos> Saviq: ↑↑↑
[08:18] <tsdgeos> didrocks: ↑↑↑
[08:19] <didrocks> tsdgeos: first reboot will take an additional 25s
[08:19] <didrocks> tsdgeos: because whoopsie collect the crash
[08:21] <tsdgeos> so we're marking something critical for 25s
[08:21] <tsdgeos> not sure which qualification we'll use when we delete user data unexpectedly :D
[08:22] <didrocks> tsdgeos: 25s on mako, seems to be 2 minutes on maguro
[08:22] <didrocks> tsdgeos: so no, I was happy to ignore the crash, until we realized that
[08:22] <didrocks> tsdgeos: seems it's an unity-mir issue
[08:36] <Saviq> didrocks, FWIW I'm not even seeing such long reboot times - apport seems just interrupted here on reboot
[08:37] <didrocks> Saviq: it's only the first boot
[08:37] <Saviq> didrocks, re-boot
[08:37] <didrocks> after you removed the crash file
[08:37] <Saviq> didrocks, and yes, not seeing that
[08:37] <didrocks> waow, can get multiple people confirming it
[08:38] <Saviq> didrocks, I'm not saying you can't, just mentioning - tried to repro that behavior and couldn't
[08:38] <didrocks> Saviq: the maguro tests were reported to me, I can only confirm the mako one thogh
[08:38] <didrocks> though*
[08:39] <didrocks> let's see once greyback is around what effort it is to fix it
[08:39] <didrocks> oh, a greyback! :)
[08:40] <greyback> didrocks: which bug? The stop unity8 crash?
[08:40] <didrocks> greyback: yeah
[08:41] <didrocks> I think I got the other regressions fixed (just need one testing again)
[08:41] <greyback> didrocks: am on it now. Hopefully isn't much work
[08:41] <didrocks> so you're the last one potentially :)
[08:41] <didrocks> and then, we can repromote an image
[08:41] <greyback> ok
[08:41] <didrocks> thanks greyback!
[08:41] <didrocks> greyback: we'll probably just cherry-pick it FYI
[08:41] <greyback> didrocks: gotcha
[08:41] <didrocks> greyback: on latest Mir version (libmirserver10 then) released in the distro
[08:42]  * didrocks doesn't want to risk more
[09:04] <didrocks> greyback: no pressure, but confirmed you are the last issue :)
[09:04] <greyback> didrocks: yep, that was clear the first time :P
[09:04] <didrocks> (phew, almost there ;))
[09:05] <didrocks> greyback: well, I didn't get my GSM dummy fix confirmed, done now :p
[09:05] <didrocks> I just raced with you, but mine was easier TBH
[09:05] <didrocks> ;)
[09:05] <greyback> :)
[09:11] <greyback> didrocks: where's the best place to get mir 0.1.2? the mir staging ppa?
[09:11] <didrocks> greyback: hum, please, use 0.1.1
[09:11] <didrocks> greyback: I don't plan to add another variable of change on the phone
[09:12] <didrocks> and just use 0.1.1+14.04.20131120-0ubuntu1 that we ship
[09:12] <didrocks> with unity-mir + your patch
[09:12] <greyback> didrocks: ok, for some reason I thought 0.1.2 has exposed this bug.
[09:12] <didrocks> greyback: no, it's really latest in trusty
[09:12] <didrocks> (and latest phone promoted image)
[09:13] <greyback> ok
[09:23] <greyback> Saviq: didrocks: can either of you have a look? https://code.launchpad.net/~gerboland/unity-mir/fix-shutdown-crash/+merge/196677
[09:23] <Saviq> greyback, am
[09:23] <greyback> ta
[09:23] <Saviq> greyback, oh, nice catch
[09:24] <greyback> Saviq: yeah, I've learned lambda functions as slots are dangerous
[09:24] <Saviq> greyback, which totally makes sense
[09:24] <greyback> indeed
[09:24] <didrocks> oh interested
[09:24]  * didrocks didn't know about that one
[09:24] <greyback> but they're so pretty
[09:34] <tsdgeos> greyback: why dangerous?
[09:35] <tsdgeos> ah
[09:35]  * tsdgeos reads the MR
[09:36] <tsdgeos> greyback: good catch!
[09:36] <greyback> tsdgeos: yeah. I guess we should ensure if you use lambda slot, it does not capture anything, i.e. is of form "[]"
[09:37] <greyback> so there's no side effects
[09:38] <tsdgeos> yeah :/
[09:38] <tsdgeos> https://code.launchpad.net/~aacid/unity8/queuedModelCountChanged/+merge/196680 anyone?
[09:41] <Saviq> didrocks, mir not yet published, you said you want to cherry-pick unity-mir
[09:41] <Saviq> didrocks, but unity-mir trunk already build-depends on new mir
[09:41] <Saviq> didrocks, shall we revert that b-d? especially since it FTBFS...
[09:44] <Saviq> greyback, ↑↑
[09:44] <greyback> Saviq: I say revert
[09:44] <Saviq> greyback, ok with me uncommitting?
[09:44] <greyback> Saviq: yep
[09:44] <Saviq> greyback, you'll have to rebase your branch
[09:44] <greyback> Saviq: I know, it's grand
[09:45] <didrocks> no, don't worry
[09:45] <didrocks> I don't want to take the other commit as well
[09:46] <didrocks> greyback: Saviq ^
[09:46] <didrocks> I just tested current unity-mir
[09:46] <didrocks> + the pathc
[09:46] <didrocks> and yeah, no crash
[09:46] <didrocks> I'm cherry-picking directly in distro
[09:46] <greyback> \o/
[09:46] <didrocks> and get the changelog fixed
[09:46] <didrocks> let's do it quickly
[09:46] <Saviq> didrocks, ok then
[09:46] <didrocks> nice work greyback!
[09:46]  * greyback takes rest of the day off
[09:46] <didrocks> Saviq: but clearly saw we need trunk linked to delivery in ubuntu :)
[09:46] <didrocks> greyback: can I as well? :)
[09:46] <didrocks> we have -proposed stuck for another fix :(
[09:47] <greyback> didrocks: ask Saviq, he's always letting me take days off ;)
[09:47] <Saviq> didrocks, sure, go for it
[09:47] <Mirv> greyback: :D
[09:47] <Mirv> cool to have the fix so quickly
[09:48] <Saviq> didrocks, greyback so anyway we're still blocked for merging into lp:unity-mir due to FTBFS against new mir (and it not being published, for that matter)
[09:48] <Mirv> you could merge the patch plus changelog manually and use bzr commit --author, while waiting for Mir
[09:48] <greyback> Saviq: new Mir being 0.1.2? I'd better fix that FTBFS then
[09:49] <Saviq> greyback, yes
[09:49] <didrocks> Saviq: feel free to merge manually
[09:49] <Saviq> greyback, https://bugs.launchpad.net/unity-mir/+bug/1254986
[09:49] <didrocks> Saviq: it's a build-dep issue?
[09:49] <didrocks> ah, something else
[09:49] <greyback> Saviq: is it available in a PPA somewhere? I'm not sure I trust mir-staging
[09:49] <didrocks> ok
[09:49] <didrocks> I'll let you guys figure it out :)
[09:50] <greyback> Saviq: in bug, nvr mind
[09:50] <Mirv> greyback: ppa:ubuntu-unity/daily-build
[09:50] <greyback> Mirv: so I saw, thanks for that. I always forget that ppa
[09:51] <didrocks> greyback: I added the changelog diff to your MP
[09:51] <didrocks> greyback: Saviq: uploaded to unblock the image, thanks guys!
[09:51] <greyback> didrocks: thank you
[09:51] <Saviq> didrocks, uh, already kicked generic-land
[09:52] <Saviq> didrocks, care to push the changelog yourself / do an MP?
[09:52] <didrocks> Saviq: no worry, doing it
[09:53] <greyback> didrocks: done
[09:53] <didrocks> greyback: Saviq: https://code.launchpad.net/~didrocks/unity-mir/resync-changelog/+merge/196682
[09:54] <greyback> uhh, to late
[09:54] <Saviq> didrocks, greyback landing
[09:54] <didrocks> land whatever you want, just need the changelog to be in sync :)
[09:55] <Saviq> tsdgeos, so we were trigger-happy with countChanged were we
[09:55] <tsdgeos> a bit too soon i'd say
[09:56] <Saviq> tsdgeos, would approve, if not for bug #1254898 :/
[09:59] <tsdgeos> Saviq: hmm, how common is that? and what does this have to with the other thing?
[09:59] <tsdgeos> or shall we not merge anything until we fix that one?
[10:00] <Saviq> tsdgeos, it's not that we *shall*
[10:00] <Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/
[10:00] <tsdgeos> ok
[10:01] <Saviq> tsdgeos, it's just blocking us - think I found the issue, though
[10:01] <tsdgeos> lots of yellow
[10:01] <tsdgeos> haven't been paying attention lately it seems
[10:06] <mzanetti> greyback: hey, I guess the ApplicationManager has the same issue: https://code.launchpad.net/~aacid/unity8/queuedModelCountChanged/+merge/196680
[10:13] <greyback> mzanetti: whoa, that's interesting.
[10:13] <mzanetti> greyback: yeah... tsdgeos discovered it
[10:13] <tsdgeos> greyback: it's not always bad
[10:13] <tsdgeos> but it was happening to me
[10:14] <tsdgeos> that someone got the countChanged Signal before a third party (a repeater) was getting the insertedRows
[10:14] <mzanetti> yep. I think we're not running into this with applicationmanager yet as we don't do fancy stuff onCountChanged
[10:14] <tsdgeos> and so when the countChanged handler wanted to do stuff on the repeater it was weirded out by the fact that the row was still not there
[10:15] <tsdgeos> and i really think it makes sense all rowInserted are processed before any count changed is invoked
[10:15] <mzanetti> tsdgeos: but... shouldnt that stuff happen on Repeater.countChanged instead of mode.countChanged?
[10:15] <mzanetti> model
[10:15] <tsdgeos> mzanetti: well it's the decoulping problem
[10:16] <tsdgeos> a item is responsible for something and a different item fro something else
[10:16] <mzanetti> ah... right... we have that thing in the indicators
[10:16] <tsdgeos> mzanetti: yes in an ideal world, yeah, and it was my first idea of fixing it
[10:16] <tsdgeos> mzanetti: but then i did think about it and if we were not chaining the signals, we'd do "endInsertSignals(); emit countChanged();"
[10:17] <tsdgeos> and that means
[10:17] <tsdgeos> first all rowsInserted and them all countChanged
[10:17] <tsdgeos> so i thought we ought to mimic that behaviour
[10:18] <tsdgeos> Cimi: ping
[10:21] <Saviq> that time of the year again :D http://ubuntuone.com/2Cf5YYEfHQ96YgIdGFyVAq
[10:22] <tsdgeos> you mean that time of the decade ^_^
[10:22] <Saviq> tsdgeos, no, that's not radioactive fallout ;)
[10:26] <Cimi> tsdgeos, pong
[10:26] <Saviq> tsdgeos, ouch, your queued connections break some tests
[10:26] <Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/unity8-trusty-i386-ci/262/console
[10:27] <tsdgeos> darg
[10:27] <tsdgeos> Cimi: i am not sure i see the problem you were saying yesterday
[10:27] <Cimi> tsdgeos, what?
[10:27] <tsdgeos> Cimi: you said "open preview in carousel, switch left/right to other items"
[10:27] <tsdgeos> no?
[10:27] <Cimi> tsdgeos, y
[10:27] <tsdgeos> and what should i see?
[10:27] <Cimi> tsdgeos, look at the bottom
[10:28] <tsdgeos> i am
[10:28] <Cimi> tsdgeos, the small carousel
[10:28] <tsdgeos> i even put my finger in the screen :D
[10:28] <tsdgeos> seems like stuff is in the same place to me
[10:28] <Cimi> mmmm
[10:28] <Cimi> tsdgeos, it moves up at the first swipe
[10:28] <tsdgeos> ok, i'll put my finger again
[10:29] <Cimi> tsdgeos, it's clear, especially in tablet mode
[10:30] <tsdgeos> Cimi: ok, yes, it does
[10:30] <tsdgeos> big finger :D
[10:34] <tsdgeos> Saviq: yeah that's rather unfortunate :-/
[10:34] <Saviq> tsdgeos, indeed
[10:34] <tsdgeos> i can change the qcompare
[10:34] <tsdgeos> to qtrycompare
[10:34] <tsdgeos> and then it kind of works
[10:35] <tsdgeos> but it highlights the need of a eventloop
[10:35] <mhr3> sil2100, how are we looking on unity-scopes-api?
[10:36] <tsdgeos> Saviq: so maybe i should just discard this change and as mzanetti says make the other thing able to cope with countChanged possibly happening before all the rowInserted have been processed
[10:36] <mzanetti> tsdgeos: I didn't say that :)
[10:37] <tsdgeos> mzanetti: you didn't say to discard it, you did say to make the other stuff work, no?
[10:37] <mzanetti> tsdgeos: I said the onCountChanged in the view should happen onCountChanged in the view instead of the onCountChanged of the model
[10:38] <tsdgeos> ok ;-)
[10:40] <Saviq> tsdgeos, yeah, it did feel slightly funky indeed
[10:41] <tsdgeos> ok, let's discard it for the moment
[10:41] <tsdgeos> and let's try to make it work
[10:41] <tsdgeos> everyone keep in mind that countchanged in the model may trigger before the view is updated
[10:41] <tsdgeos> and that's it :D
[10:42] <tsdgeos> let's see if i can do that in the code i'm trying to fix
[10:43] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity8/fix-dashshown-test/+merge/196690
[10:43] <Saviq> mzanetti, it's http://s-jenkins:8080/job/unity-phablet-qmluitests-trusty/422/ minus debug logging
[10:44] <Saviq> so the first green run since yesterday http://s-jenkins:8080/job/unity-phablet-qmluitests-trusty/
[10:46] <Saviq> /food, thus
[10:53] <Mirv> tsdgeos: Saviq: FYI Qt 5.2 status update, with sensors rebuilds I got rid of the previous linker error. now it has a linker error about UI Toolkit, which FTBFS:s (test failure) and I've pinged sdk team about that bug
[10:53] <tsdgeos> tx!
[10:54] <Saviq> Mirv, cheers!
[11:04] <greyback> Mirv: Saviq: https://code.launchpad.net/~gerboland/unity-mir/0.1.2-supprt/+merge/196693 fixes Mir 0.1.2
[11:06] <Saviq> didrocks, ↑ what do we do? are we publishing new Mir first and letting that through or are we testing locally and forcing it in?
[11:07] <didrocks> Saviq: as long as it's tested in a good variety of hardware, I have no issue with you doing a manual MP
[11:07] <didrocks> Saviq: you clearly need feature ticket ;)
[11:08] <Saviq> didrocks, airline CI there yet? :P I don't want to do manual, so asking what's the proper course here
[11:08] <didrocks> Saviq: if only ;)
[11:08] <Saviq> didrocks, I'd rather wait for mir to be released
[11:08] <didrocks> Saviq: yeah, sounds fine
[11:09] <Saviq> k
[11:10] <Mirv> but one can't build the trunk in PPA without the fix? previously I've merged manually, build mir + platform-api + unity-mir + unity-system-compositor in the PPA, tested them and released at the same time
[11:15] <sil2100> mhr3: I sent it out for preNEW review, but for now nothing
[11:16] <sil2100> Argh, I meant:
[11:17] <sil2100> mhr3: I sent it out for preNEW reveiw yesterday, but for now there is no info regarding how it went
[11:27] <Cimi> mzanetti, in that branch, we should probably check if clicking on items it hides indicators? https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965
[11:28] <mzanetti> Cimi: yeah... that test seems a bit minimalistic
[11:33] <tsdgeos> Cimi: so yeah basically is the "up" animation that messes things up
[11:33] <Cimi> tsdgeos, up animation?
[11:33] <tsdgeos> Cimi: for first show animation is still not there so Y is 158.237 and for the second is already there so it's 170.038
[11:34] <tsdgeos> Cimi: you know that thing that makes the item "grow" or whatever in the carouse
[11:34] <tsdgeos> l
[11:34] <tsdgeos> which tbh i don't know why it's happening
[11:34] <tsdgeos> since it's the same item we had selected
[11:34] <tsdgeos> am i making any sense?
[11:34] <Cimi> tsdgeos, it's just a scale
[11:34] <tsdgeos> sure
[11:34] <Cimi> tsdgeos, it should not affect
[11:35] <tsdgeos> it does
[11:35] <Cimi> tsdgeos, scales don't affect coordinates
[11:35] <Cimi> afaics
[11:35] <tsdgeos> they don't affect coordinates
[11:35] <tsdgeos> they do affect mapToScene though
[11:36] <tsdgeos> hmmm
[11:36] <tsdgeos> or maybe not
[11:36] <tsdgeos> let me make sure
[11:39] <Cimi> tsdgeos, you can disable the scale and see
[11:39] <Cimi> tsdgeos, I think I did though
[11:43] <tsdgeos> ok
[11:52] <dandrader> "FAIL!  : qmltestrunner::Shell::test_DashShown(in focus) Uncaught exception: Cannot read property 'width' of undefined"
[11:52] <dandrader> does anybody knows what's that about ↑
[11:52]  * dandrader is now using the arrow char as well :)
[11:56] <tsdgeos> Cimi: http://paste.ubuntu.com/6478600/ does defenitely make it go away
[11:56] <tsdgeos> dandrader: yes, Saviq is merging a fix for it
[11:56] <dandrader> tsdgeos, cool. thanks
[11:57] <tsdgeos> Cimi: can you confirm?
[12:03] <nic-doffay> Saviq, you around?
[12:11] <sil2100> mhr3: https://code.launchpad.net/~sil2100/unity-scopes-api/package_name/+merge/196700 <- with this in, we're ready to go with enabling in cu2d!
[12:15] <mhr3> sil2100, thx, approved
[12:16] <seb128> sil2100, mhr3: +1
[12:24] <Saviq> nic-doffay, here
[12:25] <nic-doffay> Saviq, re this: https://code.launchpad.net/~nicolas-doffay/unity8/category-transition-speed-fix/+merge/195203
[12:25] <nic-doffay> Not quite sure how to get around the speed issue without other issues occurring with this approach.
[12:31] <tsdgeos> dandrader: saviq stuff merged
[12:31] <Saviq> tsdgeos, dandrader I'll take care of restarting merges
[12:32] <Saviq> nic-doffay, why would the speed different, when you have the same amount of travel and same duration?
[12:32] <dandrader> Saviq, thanks. and don't forget about finishing the review of https://code.launchpad.net/~dandrader/unity8/runningAppsEndClose/+merge/196257 ;)
[12:33] <nic-doffay> Saviq, that's the thing the travel isn't always the same. I had to add some clauses due to other bugs that occur.
[12:33] <Saviq> dandrader, I never started ;P
[12:33] <nic-doffay> Which you mentioned in a previous comment.
[12:33] <Saviq> nic-doffay, why isn't it the same?
[12:33] <Saviq> nic-doffay, it should be
[12:33] <Saviq> nic-doffay, will have another look soon
[12:34] <nic-doffay> Saviq, if you set the speed to the scope height then reset it to the collapsed/uncollapsed height as you suggested you can see a noticeable change.
[12:34] <nic-doffay> Basically like a bounce.
[12:39] <Cimi> tsdgeos, yes
[12:39] <Cimi> tsdgeos, so what we do here is unknown :)
[12:40] <tsdgeos> well now that we know what happens we can try to find out how to fix/workaround it
[12:40] <tsdgeos> i'll have a look after lunch
[12:49] <Cimi> tsdgeos, yeah I think that when it changes currentIndex position etc is screwed up maybe because it's still animating
[12:49] <tsdgeos> may be, now lunch!
[12:57] <Cimi> tsdgeos, don't answer if you're eating, that's how I do :P
[13:08] <mhr3> Saviq, do we need something in the json card templates that specifies how many lines of text should be reserved to the title?
[13:09] <mhr3> Saviq, otherwise apps cards would look like music ones (minus the subtitle)
[13:09] <mhr3> Saviq, plus how are we going to specify the different card sizes? will the json include size in grid units or something?
[13:09] <Saviq> mhr3, this might have changed, but last I checked it was "up to two lines for title+subtitle"
[13:10] <Saviq> mhr3, so if there's no subtitle - title can span two lines, but if there's subtitle - title just one line
[13:10] <mhr3> Saviq, so current music renderer can't be done using the templates?
[13:10] <mhr3> music-grid that is
[13:10] <Saviq> mhr3, meaning 2 lines for title + 1 line subtitle?
[13:10] <mhr3> as it has two lines + subtitle
[13:11] <mhr3> right
[13:11] <Saviq> mhr3, yeah that was the plan last I read it, but I vaguely remember that changing
[13:11] <Saviq> mhr3, either way, no, I don't think we should do so much for specifying it
[13:12] <mhr3> Saviq, what about the card sizes?
[13:12] <Saviq> mhr3, it should adapt dynamically
[13:12] <Saviq> mhr3, card sizes
[13:12] <Saviq> mhr3, we definitely need small/medium/large to be in the json
[13:12] <Saviq> mhr3, which translate to GUs
[13:13] <Saviq> mhr3, we shouldn't need to allow arbitrary sizes, but that's also something that wasn't clear in the spec
[13:13] <mhr3> i'm just wondering whether that'll be enough
[13:13] <mhr3> at least looking at the visual spec and what have in the jsons... might be missing stuff
[13:14] <Cimi> Saviq, what shall I do with this? https://code.launchpad.net/~cimi/unity8/fix-1214423/+merge/192868
[13:14] <Saviq> mhr3, oh yeah jsons are not complete for sure
[13:14] <Cimi> Saviq, we have a WIP doc here https://docs.google.com/a/canonical.com/document/d/1Ded64oMdX10F5vYPoarUVle-J7qLs9-ilyPtoIZoUwU/edit
[13:15] <Saviq> Cimi, reply to the comments at least ;)
[13:15] <Cimi> Saviq, basically I put myself on hold on that
[13:15] <Cimi> sdk or not?
[13:15] <mhr3> Saviq, is someone already working on creating a renderer out of the json?
[13:16] <Saviq> Cimi, if it's going to the SDK, probably doesn't make sense to get it into unity8 first
[13:16] <mhr3> Saviq, cause i'm not if you're expecting me to :)
[13:16] <Cimi> Saviq, exactly
[13:16] <Saviq> mhr3, I'm not (expecting you to)
[13:16] <Saviq> mhr3, and I am, when I can
[13:17] <mhr3> Saviq, think we should sync up on what we expect to have from each other for next week ;)
[13:18] <Saviq> mhr3, I expect to have a first iteration of the card renderer that will read the json and adapt accordingly
[13:18] <Saviq> mhr3, stand alone, tested
[13:19] <Saviq> mhr3, so no dependency on you
[13:19] <mhr3> good, i should have things prepared to hook it up to real scopes
[13:19] <mhr3> then we just need real scopes :)
[13:21] <Cimi> https://bugs.launchpad.net/unity8/+bug/1253067
[13:21] <Cimi> really that bad???
[13:22] <Saviq> Cimi, icanhascommentrightsonthatdoc? kthxbai
[13:22] <Cimi> Saviq, tak
[13:22] <Saviq> Cimi, I'd say that bug is just something not working right, not actual issues
[13:23] <Cimi> yeah
[13:23] <Cimi> Saviq, I thought it would have been faster than compiz
[13:23] <Cimi> Saviq, however, all the ubuntu shapes are consuming shaders, right?
[13:24] <Saviq> Cimi, as does most of QML itself anyway
[13:24] <Cimi> ok
[13:24] <Saviq> Cimi, it's not a magic word, or a magic resource hog ;)
[13:24] <Saviq> Cimi, and compiz/unity7 is made out of shaders just as well
[13:24] <Cimi> Saviq, well, intel 915 has limited shader units
[13:25] <Cimi> not sure which one is more graphically intense on this regard
[13:25] <Saviq> Cimi, lower than Galaxy Nexus? doubt it ;)
[13:25] <Cimi> Saviq, unity7 on the intel 915 has fallback mode
[13:25] <Cimi> Saviq, no blur iirc
[13:26] <Cimi> Saviq, to use less shaders
[13:26] <Cimi> like maybe not gaussian but mipmap or not blur at all
[13:27] <Cimi> galaxy nexus might have more updated OpenGL specs
[13:27] <Cimi> specs/support
[13:29] <mhr3> just let i915 die
[13:29] <mhr3> it had a good run
[13:29] <mhr3> but we have real gpus now
[13:35] <Cimi> mhr3, so we should let the galaxy nexus and nexus 4 die as well?
[13:35] <Cimi> we have so much performance work to do...
[13:35] <Cimi> I'd stop working on unity new features just to improve performance
[13:39] <mhr3> Cimi, i didn't say anything about galaxy nexus, i'm talking about i915 which is super old gpu that doesn't even do opengl es
[14:03] <mhr3> tsdgeos, re the countchanged branch, afaict you'd have to compress those events to be safe
[14:03] <Saviq> aaaah I got a typing machine in my phone!
[14:04] <tsdgeos> mhr3: hmmm?¿
[14:05] <mhr3> tsdgeos, oh wait it doesn't include the actual count
[14:05] <mhr3> still, the qt guys had a good reason not to expose a count property on the models :)
[14:05] <tsdgeos> mhr3: actually they did
[14:06] <tsdgeos> just in the qml models though
[14:06] <tsdgeos> because they never thought people would want to share the same interface with something that can be either a qml model or a c++ one
[14:06] <tsdgeos> ...
[14:06] <tsdgeos> ...
[14:06] <mhr3> would be nice if we could get rid of them too then
[14:06] <Saviq> now that's what I like to see http://s-jenkins:8080/job/unity-phablet-qmluitests-trusty/
[14:07] <tsdgeos> mhr3: ? what issue do you have with count?
[14:07] <Saviq> mhr3, there's rowCount and columnCount on the models all the same?
[14:08] <mhr3> tsdgeos, it's just weird to have it a notifiable property
[14:08] <tsdgeos> why?
[14:08] <mhr3> as a*
[14:08] <mhr3> cause count changes when rows dis-/appear
[14:08] <mhr3> a separate signal is just asking for all the trouble you're expriencing
[14:09] <tsdgeos> not really
[14:09] <tsdgeos> my problem is just because our implementation sucks
[14:09] <tsdgeos> not because anything else
[14:11] <mhr3> but it sucks cause there's no correct way to do it
[14:11] <tsdgeos> right, i just need to change the Qt code to do it right unfortunately
[14:12] <mzanetti> MacSlow: is the fullscreen notifications ready for review?
[14:14] <MacSlow> mzanetti, yup
[14:14] <MacSlow> mzanetti, oh... let me push it... :)
[14:14] <mzanetti> MacSlow: ok... there's a ton of conflicts. can you merge those?
[14:14] <MacSlow> mzanetti, yeah... that's solved...
[14:15] <mzanetti> nice
[14:17] <MacSlow> mzanetti, r493 pushed
[14:17] <MacSlow> mzanetti, if you want to test it with the fullscreen simunlock, plain lp:unity-notifications will do
[14:18] <MacSlow> mzanetti, regarding the stand-alone example I mean
[14:23] <mzanetti> MacSlow: I'll run it on the device with the real sim pin
[14:23] <MacSlow> mzanetti, you're lucky you have a locked sim :)
[14:24] <mzanetti> MacSlow: ?
[14:24] <MacSlow> mzanetti, I only have an unlocked sim, which fits into my GN
[14:24] <Saviq> MacSlow, you can lock it ;)
[14:24] <mzanetti> …
[14:25] <mzanetti> MacSlow: and: you could even make the other fit in there :D
[14:25] <MacSlow> Saviq, nope... two different form-factors on the simcards/slots and I don't have an adapter
[14:25]  * mzanetti has a bunch of self made adapter for all his self cut sims
[14:25] <Saviq> MacSlow, excuses, excuses
[14:25] <MacSlow> mzanetti, hm... too fiddly for my taste
[14:26] <mzanetti> MacSlow: and: you can use qdbus to lock the sim with Ubuntu Touch
[14:26] <MacSlow> Saviq, I just don't want to mess things up  :)
[14:26] <Saviq> MacSlow, that's the only way to have things to fix, though!
[14:26] <mzanetti> anyways. you can also fiddle with all sorts of python stuff to mock it if you find that less fiddlier :)
[14:27] <MacSlow> mzanetti, well I have done that already so :)
[14:27]  * Saviq is pretty interested in how will www.knowroaming.com pan out
[14:27] <MacSlow> mzanetti, what's the qdbus way to lock it
[14:28] <mzanetti> MacSlow: something like "qdbus --system org.ofono /ril_0 or.ofono.SimManager.LockSim"
[14:30] <Saviq> mterry, notes
[14:30] <Saviq> ;)
[14:33] <Saviq> mterry, you got off the hook ;)
[14:33] <mterry> Saviq, :)
[14:53] <MacSlow> Saviq, ah... just realoaded the page again (https://code.launchpad.net/~macslow/unity8/notification-fullscreen-support) and the conflicts are gone now... phew
[14:53] <Saviq> MacSlow, cheers
[14:53] <MacSlow> Saviq, LP was a bit slow then today
[14:54] <tsdgeos> Cimi: maybe we can just cheat...
[14:54] <dandrader> Cimi, I was talking about this bug: https://bugs.launchpad.net/unity8/+bug/1213956
[14:55] <Cimi> tsdgeos, that's why I wanted the rendererName :P
[14:55] <tsdgeos> Cimi: what about http://paste.ubuntu.com/6479319/
[14:55] <tsdgeos> the code in there is trying to adjust the y in case we have to show a new row of the filter grid
[14:55] <tsdgeos> but if there's just 1 row there's no need to do anything at all
[14:55] <Cimi> yeah
[14:56] <Saviq> didrocks, any word on when new mir gets published?
[14:59] <tsdgeos> Cimi: can you see if that's acceptable looking?
[15:01] <didrocks> Saviq: when they will fix the bug set on #ubuntu-mir
[15:01] <Saviq> didrocks, ok thanks
[15:02] <Cimi> tsdgeos, I'm having a look
[15:04] <greyback> dandrader: ping
[15:06] <Saviq> mzanetti, tsdgeos, we talked yesterday with mhr3 and pstolowski about what they're doing for the new scopes backend - they've created a new version of the Unity plugin, which works fine, but has the disadvantage of having to change the version number in the import statement
[15:06] <dandrader> greyback, pong
[15:06] <mzanetti> Saviq: so?
[15:07] <Saviq> mzanetti, tsdgeos, on top of that they/we'll need to diverge some of our QML soonish
[15:07] <Saviq> mzanetti, makes it difficult to switch between old and new backend
[15:07] <mzanetti> Saviq: true. but why would we want to look back after the transition?
[15:07] <tsdgeos> +1
[15:08] <mhall119> Saviq: kgunn: I'm on trusty r28, can you tell me what's going on in these screenshots? http://ubuntuone.com/0wDQmCpQCjlFzhVYrx4rb6 and http://ubuntuone.com/2G8J7z7XUuAf0sUQC9l9JI
[15:08] <Saviq> mzanetti, *after* is fine
[15:08] <mzanetti> heh
[15:08] <Saviq> mzanetti, the time between now and after is tricky
[15:08] <Saviq> mhall119, 'could not access backend storage' I'm afraid
[15:08] <mhall119> Saviq: meaning?
[15:08] <mzanetti> Saviq: well. does it mean that enabling the new backend would break lots of stuff?
[15:09] <Saviq> mhall119, can't access the images
[15:09] <Saviq> mzanetti, it doesn't work at all yet
[15:09] <Saviq> mzanetti, tsdgeos ideally we should be able to switch by just exporting a different import path
[15:09] <mhall119> Saviq: you can't access the ones I  linked to, or Unity can't access the thumbnail images?
[15:09] <Saviq> mhall119, I can't access U1
[15:09] <mzanetti> Saviq: ah... then I've read the first sentence wrong
[15:09] <tsdgeos> Saviq: yeah that'd be the best
[15:09] <mhall119> ok, I'll describe it then
[15:10] <Saviq> mhall119, or upload to people.c.c?
[15:10] <tsdgeos> Saviq: why we need to change the api?
[15:10] <mzanetti> Saviq: well... do they use unity-api?
[15:10] <mhall119> Saviq: I get blank thumbnails for some open apps, and when switching to them it seems to have to restart the app
[15:10] <mhall119> Saviq: the links work for me..
[15:11] <Saviq> mhall119, sounds like app lifecycle killed the app and the app didn't store/read its archive?
[15:11] <Saviq> mhall119, that's not all fleshed out yet
[15:11] <Saviq> greyback, ↑ sounds right?
[15:11] <greyback> reading
[15:11] <mhall119> it seems to happen a lot with webapps, but also with some QML apps
[15:11] <Saviq> mzanetti, tsdgeos, we need to change the api 'cause there's a change in approach
[15:11] <tsdgeos> ok
[15:12] <mzanetti> Saviq: so in that case the switching back/forth wouldn't work in any case
[15:12] <mhall119> Saviq: on the second one, the indicator menu and icon don't match up, I get the Battery menu on the Messaging icon, the Messaging menu on the network icon, etc
[15:12] <Saviq> mzanetti, it's on a per-component basis, really
[15:12] <greyback> Saviq: yes that would be my guess.
[15:12] <Saviq> mzanetti, there's only 5 places where we actually import Unity
[15:13] <mzanetti> mhall119: known bug
[15:13] <Saviq> mhall119, that's fixed already
[15:13] <mhall119> ok
[15:13] <mhall119> greyback: is there a way for me to provide useful information to you about the app thumbnail thing?
[15:14] <Saviq> mzanetti, what we're after is basically minimizing the divergence, i.e. until a component works with both, we don't want to make a copy of it
[15:14] <Saviq> mzanetti, tsdgeos, FWIW I wanted to split unity8 into a few Unity.UI.Foo modules in any case
[15:14] <greyback> mhall119: contents of .cache/upstart/unity8.log is handy.
[15:14] <mzanetti> Saviq: fine with me
[15:14] <tsdgeos> Saviq: that's the ideal, if you can make them decoupled enough :D
[15:14] <mzanetti> Saviq: this would be the time to make use of unity-api for the scopes stuff
[15:15] <greyback> mhall119: and do a "ps ax" on the device to check if the applications with black thumbnails are running or not
[15:15] <Saviq> mzanetti, not really, since we don't really have the new API yet
[15:15] <mhall119> greyback: and where would you like me to send the log?
[15:15] <Saviq> mzanetti, so splitting it would just be a pain at this point
[15:16] <greyback> mhall119: create a bug please
[15:16] <greyback> mhall119: against unity-mir
[15:16] <Saviq> mhall119, that's bug #1193099 btw
[15:16] <mzanetti> Saviq: how about this? We start the new one with a new version number. change all the old imports to be named imports. then we can load both, the old and the new and at some point drop the old imports
[15:17] <Saviq> mzanetti, I'd be worried that would affect what works currently
[15:17] <Saviq> mzanetti, say if the new backend's plugin crashed on init or something
[15:18] <mhall119> greyback: well, one missing app thumbnail has a running process, another doesn't
[15:18] <mhr3> mzanetti, yea, we're still changing the abi a lot, that might happen quite often
[15:18] <mzanetti> Saviq: well, unless they completely finish the new plugin and do the transition of unity to it in a single merge, there's always a high risk of breakage
[15:18] <Saviq> mhall119, and the other bug #1253804
[15:19] <Saviq> mzanetti, yeah, but we're just too early in the new stuff's dev process I think
[15:19] <mhall119> greyback: do you want a new bug, or should I just add my info to #1193099 ?
[15:19] <Saviq> mzanetti, and also, that wouldn't really help when you want to use the same type from two different named imports
[15:19] <greyback> mhall119: could you determine reliable steps to reproduce the bug please, and add them to that bug. I can't tackle it right now.
[15:19] <Saviq> mzanetti, 'cause you'd have to change the named import anyway
[15:20] <mzanetti> Saviq: well... if it doesn't do anything yet I'd say they should continue in a separate branch/repo/whatever until it makes sense starting to integrate it
[15:20] <Saviq> mzanetti, or worse - its usage
[15:20] <mhall119> greyback: only process I know is "use the phone for a while"
[15:20] <mhall119> sometimes it happens right away with only 2 apps, sometimes it takes 6 or more before it happens
[15:20] <mzanetti> Saviq: I'm not really sure what you want to hear from me tbh
[15:20] <Saviq> mzanetti, ideas ;)
[15:20] <mhr3> Saviq, mzanetti, i'd actually want to merge stuff this week, it's nowhere near complete.. and disabled by default, but we want it easy to actually play with it
[15:20] <greyback> mhall119: yuk. Ok, well just add that, I'll see what I can do
[15:21] <mzanetti> doorbell
[15:21] <mzanetti> brb
[15:21] <mhr3> Saviq, that reminds me, if there's no "home.scope" shell is weird :P
[15:23] <Saviq> mhr3, possible
[15:23] <Saviq> mhr3, that's because you said home.scope is just another scope last cycle ;P
[15:23] <Saviq> mhr3, and so we had to store that name somewhere to make it special
[15:24] <Saviq> mhr3, now we probably need to change that name
[15:24] <mhr3> Saviq, i think the issue is that shell waits for it and disables some functionality while it's not there
[15:24] <mhall119> greyback: ok, added screenshot, log, and description or running/not running processes
[15:24] <Saviq> mhr3, something like this might happen indeed
[15:25] <mhr3> Saviq, so really we should have a signal that says "loading done" and anything disabled will get away
[15:25] <greyback> mhall119: thank you
[15:25] <Saviq> mhr3, it's a string in Dash.qml
[15:25] <Saviq> mhr3, yeah, you don't have that signal either ;P
[15:26] <Saviq> mhr3, or didn't have, at least
[15:26] <mhr3> i'm blame dednick
[15:26] <mhr3> as he's on holiday :)
[15:26] <Saviq> good call
[15:27] <mhr3> Saviq, anyway, idea how to fix it for new while keeping it working for old?
[15:27] <mhr3> Saviq, Q_PROPERTY(bool loadingFinishedActuallyWorks) ;)
[15:28] <Saviq> mhr3, I'm starting to think just a branch on top of lp:unity8 will be the easiest... and easiest to integrate then
[15:28] <Saviq> mhr3, otherwise we'll end up with copies of all the files that just need one line changed
[15:29] <mhr3> Saviq, but pain to develop against, you'll have to always base on it
[15:30] <Saviq> mhr3, but then you won't have to reintegrate changes to files that were changed in trunk in your copy
[15:30] <Saviq> mhr3, or people would at least have to make sure to apply any changes to both
[15:31] <mhr3> Saviq, i just want the switch to new be as simple as possible even during development
[15:31] <Saviq> mhr3, which doesn't feel awesome
[15:31] <mzanetti> MacSlow: just ran your branch on the phone. it's nowwhere near fullscreen :)
[15:31] <mhr3> Saviq, if that means separate unity8 branch, it's already a fail
[15:32] <mhr3> ..or we need it in ppa
[15:32] <Saviq> mhr3, dunno, it feels easy enough to just have two checkouts
[15:33] <Saviq> mhr3, oh you mean for people that just want to grab packages?
[15:33] <mhr3> yes
[15:33] <mzanetti> why would someone want to do that?
[15:33] <Saviq> mzanetti, to see progress
[15:34] <Saviq> mhr3, separate branch + ppa acceptable?
[15:34] <mzanetti> in that case I guess ./run should be acceptable too
[15:34] <mhr3> meh, i guess that's what it takes
[15:34]  * mhr3 really didn't want ppa
[15:35] <Saviq> mhr3, only other idea I can think of: have a copy of Shell.qml and any other .qml files that need changes
[15:35] <MacSlow> mzanetti, you've not used the example from lp:unity-notifications I assume... so the notification you triggered didn't use the new hint for fullscreen.
[15:35] <Saviq> mhr3, but then integrating trunk changes in there will be painful
[15:35] <mzanetti> yep. that's an issue
[15:36] <Saviq> mhr3, if we try and maintain backwards compatibility between the two, we'll just stumble upon roadblocks and it will influence what we do
[15:36] <Saviq> make us jump through hoops
[15:36] <mhr3> Saviq, yea, that's true indeed
[15:37] <mhr3> Saviq, ok then, separate branch it is
[15:37] <mhr3> +ppa
[15:37] <Saviq> mhr3, let me know if you need help setting it up, + recipes and such
[15:37] <Saviq> mhr3, and I promise you we'll help with any conflict with merging trunk in there
[15:37] <mhr3> first i need unity-scopes-api in distro :)
[15:38] <Saviq> mhr3, obviously then, when there are changes that can go into trunk directly - that's where they should go straight away
[15:41] <davidcalle> sil2100, hey, could you please have a look at https://code.launchpad.net/~davidc3/cupstream2distro-config/jamendo-scope/+merge/196735 ?
[15:42] <sil2100> davidcalle: hey! Sure, I'll look into this in a moment :)
[15:43] <davidcalle> sil2100, thanks
[15:46] <mzanetti> Saviq: can't compile unity8 on the phone because qmirserver.h isn't found
[15:47] <mzanetti> installing libunity-mir-dev doesn't work because of a missing dep to libunity-mir1 >= 0.2-something
[15:47] <mzanetti> is there an issue currently or is my device borked?
[15:47] <Saviq> mzanetti, should be working, checking
[15:49] <Saviq> mzanetti, sure you don't have no ppa enabled, btw?
[15:50] <mzanetti> Saviq: yeah
[15:50] <Saviq> mzanetti, so yeah, daily-build ppa might cause it
[15:50] <Saviq> mzanetti, ppa-purge ppa:ubuntu-unity/daily-build
[15:52] <mzanetti> Saviq: nope. not installed
[15:52] <Saviq> mzanetti, not installed meaning not enabled?
[15:52] <mzanetti> yeah
[15:52] <Saviq> mzanetti, libunity-mir-dev installs fine from distro here
[15:53] <mzanetti> ah crap. I know what's happening
[15:53] <Saviq> mzanetti, apt-cache policy libunity-mir-dev libunity1 ?
[15:54] <mzanetti> Saviq: I had libunity-mir from your tgz to test the sigstop thingie
[15:55] <Saviq> mzanetti, right
[15:56] <davidcalle> sil2100, I almost sorted it before committing, that bothers me too. Next time ;)
[15:57] <Saviq> mzanetti, so yeah, apt-cache policy would've told you that
[15:59] <sil2100> davidcalle: yeah, I guess let's use a separate clean up branch and merge for that ;)
[16:22] <Cimi> tsdgeos, yeah I think I don't have better ideas now
[16:22] <tsdgeos> Cimi: i tried multiplying the result by the scale
[16:22] <tsdgeos> but didn't work at all
[16:22] <Cimi> tsdgeos, actually no
[16:23] <Cimi> tsdgeos, are we sure this will work when its not first category?
[16:24] <tsdgeos> i don't see why it should not
[16:24] <tsdgeos> but no i am not completely sure
[16:25] <Cimi> tsdgeos, I guess this moves conentY
[16:25] <Cimi> tsdgeos, sometimes contentY might need to be adjusted
[16:25] <Cimi> let me try
[16:27] <Cimi> tsdgeos, would be better getting the position of the carousel at all
[16:27] <Cimi> tsdgeos, not the current item inside
[16:27] <tsdgeos> Cimi: well, but that defeats the purpose of the code as far as i understand
[16:27] <tsdgeos> that is making sure the current item is visible
[16:28] <tsdgeos> mzanetti knows more though
[16:28] <tsdgeos> since he wrote it :D
[16:30] <Cimi> tsdgeos, seems to work actually..
[16:31] <Cimi> tsdgeos, so I'm fine with it if you want to commit
[16:31] <Cimi> tsdgeos, I was testing it in weird positions
[16:31] <tsdgeos> Cimi: ok, commiting then
[16:46] <Cimi> dandrader|lunch, not trivial to code... had a look already
[16:46] <tsdgeos> Saviq: something is missing in deps?
[16:46] <tsdgeos> Saviq: i'm getting
[16:47] <tsdgeos> CMake Error at CMakeLists.txt:64 (message):
[16:47] <tsdgeos>   Could not determine plugin installation dir.
[16:47] <tsdgeos> anyone?
[16:48] <tsdgeos> mhr3: ↑↑ ?
[16:48] <mhr3> tsdgeos, latest unity-api
[16:48] <mhr3> 7.80.4 iirc
[16:49] <tsdgeos> taht still didn't hit the repos
[16:49] <Saviq> tsdgeos, yes, latest unity-api
[16:49] <tsdgeos> why do we depend on it?
[16:49] <Saviq> tsdgeos, because it defines the path to install shell-facing plugins
[16:49] <Saviq> tsdgeos, take it from daily-build
[16:50] <tsdgeos> it's confusing when i'm using the development branch of the distro but still need the development-development branch to get stuff to work :D
[16:51] <Saviq> tsdgeos, yeah, it's not often that happens, sorry
[16:51] <Saviq> tsdgeos, it'd have been released already if not for a lot of things that obviously had to happen just now
[16:51] <tsdgeos> :D
[16:51] <Saviq> tsdgeos, actually not even daily-build...
[16:51] <mhr3> tsdgeos, clearly you pull too often ;)
[16:51] <tsdgeos> well i'm trying to not get my branch billions of hard merges to do
[16:52] <Saviq> tsdgeos, actually it's there, yeah
[16:52] <tsdgeos> but i guess i can just call it a day and wait for stuff to happen
[16:52] <Saviq> tsdgeos, it's going to be in distro real soon
[17:05] <Cimi> so it's ready for review now https://code.launchpad.net/~unity-team/unity8/dash-renderers/+merge/196285
[17:06] <Cimi> Saviq, we should really change to read only properties and do some polishing
[17:10] <Saviq> Cimi, sure, but then we're replacing all those soon...
[17:11] <Saviq> with "Dash toolkit"
[17:11] <Saviq> well, not all - some
[17:14] <Saviq> alesage, hey, could you update https://code.launchpad.net/~allanlesage/unity8/indicator-stubs/+merge/192059 somewhen?
[17:15] <alesage> Saviq, yes it's on the list, will do today
[17:15] <Saviq> alesage, great, thanks
[17:16] <Saviq> alesage, on that note... do you think you could extend it to test against a regression of bug #1253804 ?
[17:17] <Saviq> alesage, should be relatively easy
[17:17] <Saviq> alesage, just leave a note on the MP please if you managed to do it, otherwise we'll take over tomorrow
[17:18] <alesage> Saviq ok noted :)
[17:27] <Saviq> mhr3, can you provide context on https://code.launchpad.net/~unity-team/unity/changeset-demultiplexer/+merge/196291 ?
[17:28] <mhr3> right
[17:46] <Saviq> didrocks, sil2100, unity-api release was postponed for some reason? I see it's there in daily-build, but not in landing plan?
[17:51] <didrocks> Saviq: just postponed before of all the recent mess, we will resume that tomorrow :)
[17:51] <Saviq> didrocks, ok thanks
[17:51] <Saviq> didrocks, have a good evening o/
[17:51] <didrocks> thanks, you too!
[18:57] <mhall119> thanks guys for the quick update release, you rock!