=== marlinc_ is now known as marlinc === kgunn is now known as Guest55148 === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [06:36] didrocks, when I run autopilot on Saucy with Otto, I often get http://paste.ubuntu.com/5673206/ for nearly all the tests, do you know what it means ? [06:36] and in dbus.log http://paste.ubuntu.com/5673216/ [06:39] jibel: sounds like zeitgeist is crashing, but mhr3 is on holidays… [06:39] or can't create its database [06:39] activity.sqlite doesn't exist I guess? === mamad is now known as boynux [07:30] \q [08:41] Does anybody knows how can I contribute to UnityNext project? [08:44] boynux, hey [08:44] boynux, it's a slightly difficult time as everything is so fluid right now [08:44] hi [08:45] and we definitely need to get better in enabling you guys to do so [08:45] but we have a list of TODOs and FIXMEs some of which are bite-size [08:45] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoGvOYxwuvpFdEJ5dURFb3Y0cnlKeEcxc0piNDZrWXc#gid=0 [08:45] so, is there any list or irc channel just to have an idea how to start? [08:45] IRC is here [08:46] ok, thanks [08:46] and we don't have a specific ML, and ubuntu-phone is a good enough place (as you've noticed) [08:48] yes, I understand. and is there any possibility to take some of the tasks in that google doc? [08:48] boynux, there's an "owner / assigned" column [08:48] boynux, just drop yourself in there [08:49] ok, fine. [08:49] but there is no time frame for tasks! [08:50] boynux, the "Difficulty" should be an indication [08:51] boynux, if by time frame you mean how time consuming a task is [08:51] boynux, there's also the set of blueprints you can reach from https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0 === gusch is now known as gusch|away [08:52] boynux, where, if you find a TODO item (even if it's assigned to someone) that you'd like to work on, ping me about it [08:53] Saviq, thanks for all information. [08:53] ok! [08:53] and the code base is the one from bzr? right? [08:53] also can you tel me how to send out patches afterward? [08:53] boynux, lp:unity/phablet [08:54] boynux, https://dev.launchpad.net/UsingMergeProposals is our process [08:58] Saviq, OK, I think now I have enough info to to digest for the moment :) thank you. [08:58] boynux, cheers, feel free to ping me or just hang out here if I'm unavailable [08:59] Saviq, sure, thank you. [09:14] biab [09:15] greyback: oh man, can't get the lvwph test to pass once i move from the broken tryCompare to the non broken one :/ [09:15] i mean, they pass locally [09:15] but not in jenkins :D [09:15] tsdgeos: I sympathize. One fail in particular, or several? [09:15] several :/ [09:16] point me to a branch, I might be able to help [09:16] lp:~aacid/unity/fix_tryCompare [09:17] latest failures http://10.97.2.10:8080/job/unity-phablet-qmluitests/913/ [09:17] after billion of different permutations :/ [09:31] tsdgeos: weird thing I found while reading source to qtquickcontrols, specifically the ScrollView code, it always adds a non-zero arguments to the flick call [09:31] with a comment "flick() does not work with 0 yVelocity" [09:32] tsdgeos: also I'm not convinced the mouseFlick function always works well [09:32] greyback: we need it [09:33] flick doesn't want to flick up [09:33] when you're up [09:33] so either we kill that test [09:33] or [09:33] I see [09:36] tsdgeos: I think we need a better solution for testing Flickables then. I don't think we can reliably manipulate them via JS [09:36] so I would vote for disabling the tests which we suspect are unreliable, and look for a better solution. Probably C++ based [09:37] tsdgeos: just a random thought, what GU size is set on jenkins? [09:37] not sure [09:37] mzanetti: ? [09:38] none [09:38] which defaults to 10 afaik [09:38] greyback: tsdgeos ^ [09:38] may be [09:39] TO ALL: i've just accidentily overwritten lp:unity/phablet. :( please noone pull latest until we get it resolved [09:39] tsdgeos: yep that caused a fail [09:39] anyone know how to get the latest good revision back? [09:39] * mzanetti wonders how that would happen [09:39] dednick: depends on what you did [09:39] i have 675, anyone has anything newer? [09:40] same here [09:40] mzanetti: i pushed with overwrite instead of pull. [09:40] me too [09:40] dednick: can you bzr uncommit && bzr revert && push? [09:41] we can ask jenkins what's the last branch it autolanded [09:41] * tsdgeos checks [09:41] mzanetti: no. the version is a few days old. [09:41] let me pull [09:41] so https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512 is the last thing merged [09:41] so 675 is fine as "last" rev [09:41] wonder if when http://s-jenkins:8080/job/unity-phablet-autolanding/327/console autolands [09:42] what will happen :D [09:42] if we're luck it causes a merge conflict and fails [09:42] otherwise... hmm. need to remerge I'd say [09:42] then we just need to push overwrite 675 again and accept that change to autoland again [09:42] should not be that "bad" [09:43] no... no biggie right now... but really interesting that this can happen... [09:44] so the revisions 655 - 675 are gone forever? there's no history or anything left any more? [09:44] didrocks: can this be locked down? We had an accidental push directly to trunk [09:44] mzanetti: well, you just push --overwrite and they'll be back [09:44] indeed [09:45] sure... but if we wouldn't have a local copy we'd be quite screwed? [09:45] probably yes :) [09:45] possibly [09:45] wow... [09:45] which is why I thought bzr was locked down that we couldn't directly push, only the tarmac/jenkins could [09:46] so... who will push 675? [09:46] mzanetti: i'd wait until the autolanding thing finishes [09:46] tsdgeos: why? if your fast enough it won't be noticed by the job [09:46] ah it finished [09:46] but the 675 MP doesnt have the full history does it? [09:46] and it merged [09:47] :S [09:47] let's just push overwrite, and re-propose the merge [09:47] ack. I'm on re-proposing the merge... you guys push in the meantime [09:48] but I'd like didrocks ' opinion before proceeding, just in case there's something subtle [09:48] oh wait [09:48] https://code.launchpad.net/~saviq/unity/phablet.release-176/+merge/164192 [09:48] this was merged too [09:48] 676 [09:48] you sure? [09:48] does that skip unity-phablet-autolanding ? [09:48] it says in the MP at least [09:48] plus that one has full history. [09:49] can't see it's job [09:49] greyback: I'm debugging stuff in a hangout? [09:49] didrocks: ah sorry, when you have time let us know [09:49] greyback: is it urgent? [09:50] tsdgeos: I think there is some special case for changelog-only changes [09:50] i see [09:50] tsdgeos: might not go through regular autolanding [09:50] so we need to push 675, and then reapprove that one and the https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906 one [09:50] sounds like a plan? [09:50] didrocks: kinda. We accidentally bzr push --overwrite to our trunk. We want to restore it back to a last known revision by doing the same, and then re-proposing any merges that happened in the mean time. See any problem with that? [09:50] why not just pushing this: lp:~saviq/unity/phablet.release-176 ? [09:51] mzanetti: that works too [09:51] mzanetti: if that did indeed merge, then yeah [09:51] greyback: no, sounds good to me :) [09:51] that will still work even with dailies [09:52] didrocks: ok cool, thanks. We should chat later to see if we might want to lock down us pushing directly to trunk [09:52] ok, so who pusehs lp:~saviq/unity/phablet.release-176 ? [09:52] yep :) [09:52] tsdgeos: feel free [09:52] ok, doing, give me 5 min [09:53] oh... this one failed to merge: https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906 [09:53] yep [09:53] that's "good" [09:53] so we just push Saviq's branch and set that one to Approved again and we're fine [09:53] i guess :D [09:53] yep, agreed [09:54] * dednick purges push --overwrite from .bash_history [09:54] hehe [09:55] better, yes :D [09:55] tsdgeos: you better do so too afterwards :D [09:56] how does one do that? [09:56] dednick: ? [09:56] ok, we're all set [09:56] https://code.launchpad.net/~unity-team/unity/phablet [09:56] 676 is back [09:56] and i just reapproved https://code.launchpad.net/~mzanetti/unity/phablet-tease-launcher/+merge/163906 [09:56] tsdgeos: edit ~/.bash_history [09:56] tsdgeos: cheers [09:57] dednick: huh? isn't that a binary file? [09:57] thanks all! [09:57] nope [09:57] wow... its not in ubuntu [09:57] crazy [09:57] mzanetti: never been one afair [09:58] all the distros I've used before stored the history in some binary/encrypted format [09:58] really? [09:58] interesting [09:58] now I'm confused... just checked my Archlinux based TV [09:58] also plaintext [09:58] but I'm 100% sure I've seen that encrypted already [10:01] dednick: first time my highlight filter on "all:" was useful :D [10:01] usually it only produces false positives on dh_install: pastes etc [10:01] mzanetti: ahha [10:12] oh boys, oh boys [10:13] haha [10:17] tsdgeos: what exactly is the reason why we need to depend on the fonts? [10:17] mzanetti: it's expplained in the commit log ;-) [10:17] not really... [10:17] it says otherwise a test fails [10:17] but I would like to understand why [10:18] "install the ubuntu font since we use it and otherwise the test [10:18] does not pass because font sizing is different" [10:18] font is different [10:18] sure... but why would a slightly larger/smaller font mess up the test? [10:18] pageHeader label is different [10:18] so instead of "active" [10:18] it goes into "narrowActive" [10:19] because there's not enough space [10:19] oh... I see [10:19] and the size comparison fails [10:19] tsdgeos, so the test should be made better [10:19] tsdgeos, i.e. grow the window until it goes into "active" [10:19] Saviq: well, tell whoever made the test [10:19] ;) [10:20] anyway we should depend on the font [10:20] since we use it [10:20] what's the point otherwise [10:20] true [10:20] the theme should depend on it, btw [10:21] yeah... fine with that... Just wanted to understand what exactly is happening [10:22] mzanetti, gimme a sec [10:22] ? [10:23] not sure for what... but sure... take your time [10:23] mzanetti, for tsdgeos's branch [10:23] ah [10:23] mzanetti, but go for it, we're explicitly using Ubuntu as the font family in a few places [10:23] which we shouldn't, but that's another story [10:27] mzanetti, remember the bug about buttons going through transparent when hovering? you did report it didn't you? [10:27] yeah [10:27] Saviq: when, clicking, not howering [10:27] mzanetti, yea [10:27] howering [10:27] hmm [10:28] :D [10:28] how how, I'm howering [10:28] pete-woods, some changes with the colours in the circle. [10:28] * mzanetti needs to actually pay attention to the spell checker when talking to Saviq [10:28] the outer circles I mean. [10:29] Saviq: you need that bug or did you find it? [10:29] mzanetti, I _am_ the spell checker [10:29] mzanetti, #1115071 [10:32] nic-doffay: have these changes been pushed? [10:32] No pete-woods busy talking about them still. === gusch|away is now known as gusch [10:32] okay [10:33] greyback: ok, available now :) [10:34] didrocks: all's good, we're back to normal. [10:34] Saviq: would you consider locking down bzr a little to stop us pushing directly to trunk? [10:34] great :) [10:35] greyback, not sure it's worth it, it's the first time this happened, and with bzr there's loads of copies lying around [10:35] greyback, it's not like it was the end of the world, just some panicking [10:37] greyback, and if we actually lock it down we might end up in a bigger conundrum when there's noone around that can push to it [10:38] greyback, unless it becomes a recommendation that trunks are owned by pspmteam or something [10:38] Saviq: actually, we might just limit overwrite pushes, if that's possible [10:38] Saviq: well's it handy for crisis prevention, we're just lucky there's lots of copies around. But yes it ties us down a little [10:39] tsdgeos, I don't think it ise [10:39] -e [10:39] :-/ [10:39] that'd be handy [10:39] tsdgeos, you either have write access or you don't [10:39] we'd just have to change the owner to a team that we're not all member of [10:39] sure, but does bazaar has hooks? [10:39] i mean a pre-commit hook might reject overwrite pushes [10:40] in my theorical mind [10:40] not saying that's possible at all [10:40] tsdgeos, would have to be manually installed, I think [10:40] tsdgeos, and then again, not worth it, IMO [10:40] ok [10:40] I myself have 5 copies lying around every other time [10:40] and backed up daily [10:40] http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#append-revisions-only [10:40] as my whole home dir [10:41] greyback, read the doc, that would not help with overwriting [10:41] really guys, not the end of the world :D [11:09] Saviq: there seems to be a dependency break in the new qtdeclarative5-ubuntu-ui-toolkit-plugin. it's requiring qt5.0.2 while we only have 5.0.1 in raring [11:09] dednick, yeah, 5.0.2 is in ppa:canonical-qt5-edgers/qt5-proper [11:09] Saviq: ah [11:09] thanks === MacSlow is now known as MacSlow|lunch === mmrazik is now known as mmrazik|afk [12:09] nic-doffay: just pulled some new changes from you regarding the dot sizes, and they look a bit screwed now [12:09] Try it on the phone pete-woods [12:09] No idea what it looks like on the tablet sadly pete-woods [12:10] Basically it looks screwed on the desktop but great on the phone. [12:10] nic-doffay: is that because of the screen resolution or something? [12:10] No idea why. [12:10] pete-woods, that would be my first guess. Can't say for sure though. [12:12] nic-doffay: it's gotta be screen resolution - looks okay on the tablet too [12:12] pete-woods, ok great. [12:12] Saviq, what's the reasoning behind using "#include " instead of "#include "? [12:12] dandrader, explicit [12:12] pete-woods, as long as it looks cool on the tablet too :) [12:12] dandrader, and/or consistent [12:13] nic-doffay: it's bad if we have resolution-dependent code, though [12:13] dandrader, obviously it doesn't matter that much 'cause qt5_add_modules adds the include dir anyway [12:14] remember this is going to be the desktop login screen, too, with unity next [12:14] nic-doffay: also, the arrow icon is too low resolution, it looks pretty pixelated on the tablet [12:16] Saviq, Qt documentation also omits the module dir in its include. I mean, what problem can arise from omitting the module directory? I doubt there can be a conflict (otherwise Qt docs would tell you to put the module dir when you include smthing). But ok, I'll do it as it seems to be the project's coding style (consistency) although I still don't see the point in it [12:16] pete-woods, going to commit a change, can you let me know if it makes a diff? [12:16] of course :) [12:16] pete-woods: nic-doffay isn't it because the assetts are 1:1 on the phone...but scaling on desktop ? [12:16] pete-woods, pushed. [12:17] kgunn, nope. Something else that I didn't think through properly :P [12:17] nic-doffay, pete-woods, kgunn, we just need to provide multiple @px versions of those assets, probably [12:18] Saviq, it looks fine as long as it's being scaled down. [12:18] nic-doffay, it should never be scaled up :) [12:18] So we just need to provide one large asset. [12:18] nic-doffay: actually no [12:18] nic-doffay: cause then you spend processing time :) [12:18] kgunn, that's fine [12:18] Saviq: I think it's more than that - the relative positions of the inner dots seems to be affected by the resolution [12:18] kgunn, what's the largest px? [12:18] nic-doffay, 30 [12:19] kgunn, we're going to rescale once and cache [12:19] kgunn, we can even prescale them on the servers somewhere [12:19] Saviq: that's cool [12:19] nic-doffay: at desktop resolution, the dots are too close to the centre of the circle [12:20] kgunn, so the workflow is: provide @30 and only provide others if scaling down doesn't work [12:20] pete-woods, yeah do we have to account for this though? [12:20] Saviq: nic-doffay it'll certainly work for now, and oem [12:20] 's can tweak for 1:1 [12:20] when that day comes [12:21] yup [12:23] nic-doffay: I don't think that the icon sizes are so important - as Saviq says, we can provide correctly sized ones, it's more the positioning that I think should be fixed [12:23] pete-woods, you mean for the desktop? [12:23] well, generally - there must be some mistake if the dots are going in the wrong place [12:24] as it should just be some proportion of the size of the circle [12:25] nic-doffay, pete-woods it's a regression, too, it was fine on desktop before [12:25] Saviq, yeah but it wasn't on the phone. [12:26] Saviq, the phone looks perfect now, but the desktop is screwed. [12:27] nic-doffay, that's weird, 'cause if you go GRID_UNIT_PX=16 on the desktop [12:27] Saviq: just curious...do you know if scaling is it relying on gpu to scale ? or cpu sw ? [12:27] nic-doffay, you should get exactly what you would get on the phone [12:27] kgunn, GPU right now, AFAIK, they're not cached yet [12:27] Saviq, yeah not entirely sure what is influencing the drastic differences though. At the moment I scale the object by the radius of the circle. [12:27] kgunn, when they're going to be prescaled for caching, CPU, and then nothing ;) [12:27] Saviq: so potentially you wouldn't get the same thing on phone as desktop [12:28] Sorry let me be more specific I scale the dot by the radius of the centre circle. [12:28] nic-doffay, scale it? [12:28] nic-doffay, it should always be the same size, no? [12:28] in GUs I mean [12:28] Saviq, if that's the case then we'll need those multiple assets. [12:29] nic-doffay, I think you're missing something here [12:29] nic-doffay, the size of the dot should be static in GUs, right? [12:29] nic-doffay, i.e. 1x1 GU [12:29] nic-doffay, that will mean 10x10px on desktop [12:29] 16x16px on phone [12:29] 20x20px on tablet [12:30] and QML will take care of that scaling regardless of what you give it as your asset [12:30] if there's only a @30.png asset [12:30] it will get scaled down === MacSlow|lunch is now known as MacSlow [12:30] you just don't worry about it [12:30] your asset will be 30x30 [12:30] because it's 1x1 gu @ 30 px per gu [12:31] nic-doffay, you could provide prescaled @10.png @16.png @20.png, but that's unnecessary [12:31] nic-doffay, as a dot @30 will scale down just fine [12:31] as will the arrow [12:32] nic-doffay, what's more they get cached after being scaled down [12:32] Saviq, so I shouldn't perform any scaling on the image at all? [12:32] Mirv: did you see the sdk issue? [12:33] nic-doffay, it should just be "width: units.gu(1); height: units.gu(1)" [12:33] Saviq, got it. [12:33] nic-doffay, nothing else [12:33] Mirv: on the daily release [12:33] kgunn, to clarify - IIRC they are currently cached for a single run, just not pre-cached and stored [12:34] Saviq: got it....i was following....so really, once nic-doffay goes pure gu's it should be cached by the engine [12:34] yes [12:34] re-scaled on each run [12:35] Saviq, improvement already, nice one! [12:35] right-o, i follow [12:35] Just have to fiddle around with the positioning maths a bit to compensate. [12:37] kgunn, and the end goal is that it should be pre-cached and installed in the image on a per-device basis and ad-hoc for stuff that's added to the device later [12:37] but still kept in a cache so that it's only re-scaled when needed [12:38] Saviq: sounds good...oem's will care about launch times, that'll help [12:38] yup [12:40] didrocks: yes, briefly, but I then had more urgent issues. there's a version number conflict from somewhere. [12:40] Saviq, kgunn, pete-woods fixed. [12:41] Position and size are good on desktop & phone. [12:41] Assuming tablet will be fine too. [12:41] pushing now... [12:41] nic-doffay: woohooo [12:41] Mirv: it means that a publish happened, but then, the merge back branch either wasn't merged or was reverted [12:41] nic-doffay, thought you already pushed, didn't look fixed ;D [12:41] Mirv: you will fix it before your EOD? so that we don't block next daily? [12:41] didrocks: I think I see the issue, now fixing [12:41] Mirv: thanks :) [12:41] Mirv: you can look at the publish [12:42] rev 16 [12:42] it referts to https://code.launchpad.net/~ps-jenkins/ubuntu-ui-toolkit/latestsnapshot-0.1.46daily13.05.14ubuntu.unity.next-0ubuntu1/+merge/163696 [12:43] Saviq, that was a small experiment to see what the pointer looked like on the tablet ^_^ === mmrazik|afk is now known as mmrazik [12:43] didrocks: there was actually erronous changelog manual change in the trunk, so reverting that.. [12:45] Mirv: ah ok ;) [12:45] nic-doffay: nearly there [12:45] nic-doffay, you can just go « ./run -- -fullscreen » to see how stuff looks [12:45] Mirv: at least, the daily release is defensive in that regard, so that we don't overwrite :) [12:45] you've now got the arrow as being the same size as all the dots again [12:46] nic-doffay, and « GRID_UNIT_PX=16 ./run » to see the phone in full-resolution on your desktop [12:47] nic-doffay: the dots seem to be the same size all the time now - shouldn't their size be relative to the size of the circle somehow? [12:48] i.e. if I run it in tablet mode, the dots look tiny [12:48] (but are the same size as in phone mode) [12:48] pete-woods, look fine here [12:48] * Saviq gets a few shots [12:48] pete-woods, apart from the arrow being too small, it looks fine [12:49] Saviq: I'm just running it fullscreen with no overriding resolution set, and the dots are really small [12:50] actually they look too big on the phone ;) [12:50] looks good on the actual tablet, though === greyback is now known as greyback|lunch [12:54] pete-woods, nic-doffay, so... I assumed the infographics would be static size in GUs [12:55] which it doesn't seem to be the case now [12:55] and I based my "dots should always be 1x1 GU" on that assumption [12:56] Saviq: I don't really know about GU's or anything, but I think that the dots should be some proportion of the size of the infographic circle [12:56] pete-woods, just treat GUs as a kind of "big pixels" [12:56] pete-woods, so yeah, they should definitely be a proportion of the big circle [12:57] pete-woods, but I assumed that the big circle would always be 50x50 GUs or something [12:57] which isn't the case now [12:57] the big circle scales according to the available size [12:57] and I don't know whether that's the designed behaviour or not [12:59] I thought it was the behaviour we wanted? [13:00] I dunno, design would need to say [13:00] pete-woods, btw, just noticed something [13:01] ? [13:01] pete-woods, when switching between "Guest" and "Lola Chang" [13:01] pete-woods, the circle shows up for a split second [13:02] Saviq: yes, that's because the lightdm is being told that lois is selected, briefly [13:02] I don't know what the API can do about that [13:03] pete-woods, probably nothing, we need to make sure that's not the case in the UI [13:03] it feels like the UI should only tell the API the user has changed once the selection has settled for some kind of grace period [13:03] yup [13:04] is there some proper way of doing that in QML world? [13:04] pete-woods, still hiccups when switching users, did you have time to investigate that? [13:04] I changed it to use a signal [13:04] and then subscribed to that signal [13:04] I've not spent any time performance tuning the inside of the mock implementation [13:05] that's fine [13:05]