=== jjb is now known as oao [13:28] tsdgeos: thanks for all the review bits! Let's talk about some of your questions [13:28] mterry: have you done some quick measurement if using the Canvas for the rectangle is noticeably slower? [13:29] tsdgeos: no I didn't. I hadn't considered it a critical performance path, so I didn't think of measuring it [13:58] mterry: ok [13:59] am a bit worried since it's something we create and render lots at the same time [13:59] mterry: have you put it on the phone? did you test the animation/creation wasn't "slow" [14:00] tsdgeos: it didn't look slow to me, I think one thing that helps is that they come in one by one anyway [14:00] ok [14:00] i guess QA will complain if they see something too slow there [14:00] heh, "QA will catch it" :) but yeah [14:01] I don't have a silo for that branch, so you'd need to install the deb manually [14:01] i did [14:01] but only on the laptop [14:01] mterry: i don't understand the useColor of that branch either [14:01] what is it for? [14:02] So the new design is that if we are using a non-default wallpaper, we use white for the infographic [14:02] Since we don't know what colors would work on the wallpaper [14:02] instead of what the infographics lib says [14:02] ? [14:02] ok, weird [14:02] well not weird [14:02] but ok :D [14:02] Yeah, since the lib doesn't know the wallpaper color either === JanC is now known as Guest12120 === JanC_ is now known as JanC [14:03] tsdgeos: I agree it's a bit weird [14:03] ok, that branch is fine then, i'll comment on it, not top approve since the prereq has the weird coloring for the wallpaper [14:04] tsdgeos: right... so default-wallpaper [14:05] tsdgeos: weird coloring? It didn't look bad to me [14:05] tsdgeos: I agree it's a little fuzzier [14:05] tsdgeos: so there's a comment in the code about this [14:06] 288 + // If we're using the default background, we want to cache it using the [14:06] 289 + // thumbnailer (it's quite a large file). We don't do this for all [14:06] 290 + // backgrounds, because the result can be slightly blurry (which is a [14:06] 291 + // bug we need to look into). But that blurriness doesn't really matter [14:06] 292 + // on the default background. [14:06] 293 + readonly property url cachedBackground: hasCustomBackground ? background : [14:06] 294 + "image://thumbnailer/" + background [14:07] tsdgeos: the default wallpaper file is big. It's noticeably slow to load. And so I didn't want to have the greeter background be black for a second or two every time you locked the screen or booted up [14:07] tsdgeos: I don't know why the thumbnailer isn't higher quality. I would have expected it to merely scale down, but maybe it chooses an algorithm for that more on speed than quality [14:08] mterry: do you see the difference in my screenshots? maximize them [14:08] there's quite a lot of color-banding [14:10] tsdgeos: yeah I do see that when I zoom in... [14:10] tsdgeos: so we can easily skip the thumbnailer load... [14:10] tsdgeos: you can try commenting that conditional out and just have cachedBackground: background to test that [14:11] tsdgeos: it should look much better [14:11] tsdgeos: but try it on the phone and see if you can live with the load times [14:11] tsdgeos: is there a better "cache this image at scale" solution than the thumbnailer? [14:11] no [14:12] and depending who you ask [14:12] the thumbnailer isn't that either [14:12] mzanetti had some talks with the thumbnailer guys about it [14:12] yeah? [14:12] (we use it for the dash background...) [14:12] ? [14:12] ah yeah [14:12] mterry, "out of scope" [14:12] why would a thumbnailer make thumbnails, right? [14:13] should be renamed to "media artwork fetcher" [14:13] wait, what is a thumbnailer besides a "cache this image at scale" solution? I don't get it [14:13] oh huh? it's just about extracting a representation image? [14:13] apparently [14:13] hmm [14:13] mzanetti: do we have any similar solution for scaling-and-caching? [14:13] * mterry hopes I don't just have to make it [14:14] no... haven't gotten around to implement it [14:14] but I'd need this like all the time [14:15] mterry, by accident it works for local images, but not remote ones and not if they're in a qrc [14:16] because it "extracts a representation image" from the local image [14:16] mzanetti: and it makes them all blurry anyway [14:16] I think it uses sourceSize or something [14:16] mterry: honestly to me the quality decrease looks not acceptable, and i'm usually relatively oblivious to "pretty things" [14:16] mzanetti, tsdgeos: OK. I can look into making a quick and dirty version for wallpapers for this branch... :( [14:17] mterry: i'd prefer someone else commenting if we're going to go with it [14:17] tsdgeos: no I agree. It shouldn't land. It looks worse than I thought it did, when I zoomed in. I was just looking at it on the desktop and it seemed "good enough" but as our first impression.... [14:18] tsdgeos: plus if I solve it better, we can cache any background image, not just the default one [14:18] true [14:19] tsdgeos: ok bummer, but fair [14:19] tsdgeos: now on to greeter-no-lockscreen... [14:20] tsdgeos: you can see that design on page 20 [14:21] mterry: but there it says password [14:21] tsdgeos: it's a very contentious design (as mzanetti can attest). But the designer (Alex M) is definitely on board. He's even confirmed after playing with it in a silo. It definitely makes sense for convergence and multi-users... but yeah. [14:21] i mean nowhere in that document says that number-only PINs should use the keyboard [14:21] tsdgeos: oh true... [14:21] tsdgeos: not in the document. But in meetings and such, that's been established [14:21] ok [14:22] tsdgeos: I think there's another visual doc.. let me see === dandrader_ is now known as dandrader [14:22] tsdgeos: mzanetti and I have tried to put a little pressure on Alex to reconsider the experience, but he still likes it so far [14:23] mterry: what about "proper" SIM PINs? [14:24] we do get they keyboard for that too? [14:24] or that's somehow special? [14:24] tsdgeos: I haven't changed the SIM PIN screen in this branch. The design didn't discuss that and it might actually be better if they look a little more distinct [14:24] I also didn't change entering the PIN in the wizard [14:24] or they're just not aware of it :D [14:25] This look is just for the lockscreen [14:25] so far [14:25] ok, i'll have a look now that is clear it's what they want [14:27] thx! [14:38] @unity, so I have a Loader in the greeter. If I set it to active: false, I correctly don't see any part of the Loader's item (i.e. the greeter) and can see the dash underneath. If instead I set the Loader to opacity: 0 or visible: false, I get a full-scene black rectangle on top of the dash (even if I change Loader to not take up whole screen). Any [14:38] guesses why that would be? [14:39] mterry, sure it's not things behind hiding when the loader has an item? [14:39] optimziation etc [14:39] No part of the greeter should be adjusting its parents. And no loaded item properties seem to propagate and do anything meaningful [14:41] mzanetti: ooooh... I may have found just that, thanks for the thought. I had looked in Shell.qml for that, but didn't realize that Shell passed the greeter on to the stages... Looks like they look at a loaded property to decide to be visible or not... That might just be it, thanks! [14:47] mterry, try* open a qml profiler port, can always use that to try and find out what's going on [14:47] mterry: is it me or with the greeter-no-screenslocker branch you can't have the launcher open in the locker anymore? [14:49] tsdgeos: can't have the launcher open in the lockscreen? [14:50] * mterry tries that [14:50] mterry: i swipe from the left, the launcher doesn't stay [14:50] while that' s the regular behaviour right? [14:56] hi! [14:56] fast question [14:56] I've contributed to the unity8 project, but i've been required to sign the Canonical contributor licence agreement [14:56] which I'm doing right now [14:57] there's a field asking for the Project contact...what is the Project contact of the unity8 project? [14:57] Saviq: ^ ? === dandrader is now known as dandrader|afk [15:00] kaisoz: as per http://www.canonical.com/projects/directory would be kgunn i think [15:03] yes, it has to [15:03] thx! [15:04] kaisoz: no need to answer you on launchpad, right? [15:04] i just saw the question [15:04] tsdgeos == Albert [15:05] mterry: ok, ignore me, you cna't have the launcher over the pin-entry either on current code :D [15:05] tsdgeos: I actually am able to have the launcher over both for me... Maybe I'm doing something different than you [15:06] hahaha [15:06] yes Albert, just saw your answer here :) [15:06] mterry: you can over the greeter, but not if you uncover the greeter and get the actual pin-entry [15:07] for some reason i remembered you could over the pin entry too [15:07] tsdgeos: I'm doing that right now with my no-lockscreen branch... And I tested in on the pin screen before loading the debs [15:07] tsdgeos: but... I guess in neither case (you or mine) there's a regression [15:07] So... ok [15:07] mterry: :) === dandrader|afk is now known as dandrader [15:23] mterry: Emergency only? [15:23] can't have Emergency Call like before? [15:23] or that's by design too? [15:23] tsdgeos: that's what the design has [15:23] * tsdgeos checks [15:23] tsdgeos: and no little icon either [15:24] the icon i don't call much for [15:24] but "Emergency" doesn't tell me enough imho [15:24] but ok, if design wants it that way [15:24] they can be the ones that defend it later when people complain [15:24] s/when/if [15:32] mterry: are we sure we awnt to comment out the showLastChance code? [15:32] tsdgeos: eh it's not a supported feature right now [15:32] tsdgeos: and only worked on NarrowView, not WideView [15:32] ok [15:33] I just didn't want to spend time refactoring code we aren't using === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:18] hi! === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === davmor2 is now known as davmor2_hols