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