[07:37] <Saviq> elopio, hey, I
[07:37] <Saviq> 've had to tweak the dash emulators a bit in https://code.launchpad.net/~saviq/unity8/drop-filtergrid/+merge/226336
[07:37] <Saviq> elopio, can I please ask you for a sanity check?
[08:34] <Saviq> mhr3, in case you're interested: https://code.launchpad.net/~saviq/unity8/drop-filtergrid/+merge/226415
[08:34] <Saviq> mhr3, I'll do the prelim see all/less and header links now
[08:35] <Saviq> but I've implemented collapsed-rows: 0 there
[08:35] <Saviq> and forceful expansion of single-category scope pags
[08:43] <mzanetti> oh... no more filtergrid :)
[08:52] <Saviq> mzanetti, yeah, we're letting the views do their job for maintaining delegates
[08:53] <Saviq> mzanetti, not sure why we decided otherwise before
[09:06] <mhr3> Saviq, hmm, feel like that cute dog again :/
[09:07] <mhr3> Saviq, i do like the diff stats though ;)
[09:09] <Saviq> mhr3, yeah, so, FilterGrid was something that actually applied a proxy model that limited the number of items in the model
[09:10] <Saviq> mhr3, to collapse it
[09:10] <Saviq> mhr3, but that was stoopid, since *Views just manage delegates themselves if they're out of view
[09:12] <mhr3> sounds simple when you put it that way
[09:12] <mhr3> but looking at the code, it doesn't :)
[09:13] <Saviq> mhr3, all in all, grid/journal/carousel just say "I'm yay high, but if you want to collapse me, then it's foo"
[09:13] <Saviq> mhr3, and GenericScopeView decides when to collapse
[09:14] <Saviq> mhr3, before it was the views themselves doing the expand/collapse (as you saw in your branch, the setFilter() branch that got replaced with grow()/shrink())
[09:17] <mhr3> yeah, all makes sense, i guess it's just that refactoring diffs aren't that easy to read when you're not familiar with all the relevant components
[09:22] <Saviq> mhr3, indeed
[10:18] <seb128> Saviq, bregma: is there a known slowness issue currently on untiy8 desktop? I just installed the daily and going back to the dash or opening an indicator is hanging for like 30 seconds before doing anything
[10:23] <Saviq> seb128, I'd suspect bug #1340086
[10:26] <seb128> Saviq, could be, thanks
[10:27] <Saviq> seb128, I tried pinging boiko and tiagosh about it, but never got a reply
[10:28] <seb128> Saviq, tried as well, let's see
[10:28] <Saviq> seb128, a "workaround" is to get an ofono account on your desktop, I'm not clear on how to do that, though..
[10:31] <tsdgeos> Saviq: so "All" includes "Favorites", i understand in a non favorite "All" scope we have to show the back button to go back, what about a favorite scope that we press in "All"?
[10:31] <tsdgeos> go back to regular dash? or show with the "back" button too?
[10:31] <tsdgeos> i think back button is more predicatble
[10:32] <Saviq> tsdgeos, current design is that you always go back to dash for favourites
[10:32] <tsdgeos> Saviq: even if it's in "ALl"?
[10:32] <tsdgeos> where does it say that?
[10:34] <Saviq> tsdgeos, I might have extrapolated from the comments on https://sites.google.com/a/canonical.com/unity8dash/scopes/dash-overview
[10:35] <Saviq> mikenagle, hey, just realized one thing... if bottom swipe is always meant to bring the overview, we can't open non-favourites above the overview, 'cause then if you bottom-swipe you open another overview... and then another scope, and another overview...
[10:35] <Saviq> tsdgeos, I did ask for that case transition there, never got it though
[10:35] <tsdgeos> the comments section kind of contradicts the main text too
[10:36] <tsdgeos> main text says bottom edge is disabled in "Installed, non favourite scopes opened from the overview screen"
[10:36] <tsdgeos> but then comments say "If they open it from a non favourite, installed scope, they go to the All view."
[10:36] <tsdgeos> i think i like first more
[10:37] <Saviq> tsdgeos, indeed
[10:37] <Saviq> tsdgeos, sounds like comments were earlier than the text at the top
[10:37] <Saviq> tsdgeos, text at top takes precedence of course
[10:38] <Saviq> tsdgeos, btw... not translucent here https://f966f709-a-c881af26-s-sites.googlegroups.com/a/canonical.com/unity8dash/scopes/dash-overview/01_Dash_scopes_nav_full_dark_v7.jpg?attachauth=ANoY7cpwbv7LCcNXKBgQbQooqmxRSUza5vfcPmdnUNhREphFeP9I0Ol_6CkNw5ixwLtTQxvRaJLA3nILmOGgancNaxrIfUkqoye7EgvQJFFTkCABUMCHUAXIAYMQsHaRGoLB17rIBiZ_pEfWL5hr1StfEhTegTWTUnNEx_HIFPORU236CtMZv7XQkt5tL1EOoXdimjnJsfvnC8_wif1IMvigB9WYnR_ZYzcY0qTEODhpwfvHxOctqZnhLsmbf08LMdhR7z9jwXv4YZ
[10:38] <Saviq> PLu9qqARglEYFYw42tLw%3D%3D&attredirects=0 :|
[10:39] <tsdgeos> well
[10:39] <tsdgeos> they can decide what they want
[10:39] <tsdgeos> that's the easy fi
[10:39] <tsdgeos> x
[10:39] <Saviq> yup
[10:44] <mhr3> Saviq, anyone working on the 30second hang?
[10:44] <Saviq> mzanetti, bug #1340632, sounds like live: true isn't good :|
[10:44] <mzanetti> Saviq: not sure if its related yet
[10:44] <Saviq> mhr3, I couldn't get through to boiko or tiagosh :|
[10:48] <MacSlow> What changed in the way unity8 is started (on the desktop)? The shell-UI does no come up anymore and all of a sudden I get is this output on stdout: http://pastebin.ubuntu.com/7779635
[10:53] <mzanetti> Saviq: ok... have 9 apps running now... the launcher doesn't get any more jumpy than the rest of the ui
[10:53] <Saviq> mzanetti, 9 apps *running*
[10:54] <mzanetti> Saviq: ok... have 9 apps recent now... the launcher doesn't get any more jumpy than the rest of the ui
[10:54] <Saviq> mzanetti, I misread the bug probably then
[10:54] <mzanetti> :P
[10:54] <Saviq> mzanetti, so yeah, I think we have a "shell gets slow with many apps open" bug already
[10:54] <mzanetti> yep
[10:54] <mzanetti> well, let me ask back to confirm
[10:55] <mzanetti> I'll handle that bug
[11:02] <Saviq> mzanetti, oh and it was a qtcomp bug...
[11:02]  * Saviq shuts up
[11:02] <mzanetti> Saviq: :)
[11:02] <mzanetti> no worries
[11:02] <Saviq> you probably don't even have live: true in there yet ;)
[11:02] <mzanetti> Saviq: if its landed in trunk we do. We're up to date with trunk atm
[11:02] <Saviq> k
[11:06] <tsdgeos> Saviq: i'm unsure how i'm supposed to find out which "all" scope is each, i mean they are cards, how do i get to know which scope they represent?
[11:07] <Saviq> tsdgeos, probably from uri
[11:07] <Saviq> mhr3, ↑?
[11:07] <tsdgeos> Saviq: mhr3: so we make uri return the scope_id?
[11:07] <Saviq> tsdgeos, rather a canned query
[11:07] <tsdgeos> ?¿
[11:07] <mhr3> yea, it already is
[11:07] <Saviq> tsdgeos, from which we need to take scope_id out
[11:08] <mhr3> but tbh it feels weird that we're using the standard scopes models for the super-special scopes overview
[11:09] <tsdgeos> how do i do that?  and what's a canned query (so i can create it from my fake scope)?
[11:09] <mhr3> tsdgeos, it's scope://[scope_id]?q=query_string&whatev
[11:10] <Saviq> tsdgeos, truth be told, can you not find out from openScope() / gotoScope()?
[11:10] <Saviq> not good
[11:11] <Saviq> tsdgeos, you here?
[11:11] <Saviq> mhr3, TBH I wonder if we should not get rid of openScope / gotoScope, and let the shell open the scope and pass the query to it
[11:11] <tsdgeos> i am
[11:12] <Saviq> mhr3, the "I activate, you come back with a scope" approach mechanism feels shaky
[11:12] <mhr3> Saviq, it's not just the query though, it's department id, filters state, whatever metadata
[11:13] <tsdgeos> Saviq: so you're suggesting i just call activate and the scope will emit gotoscope?
[11:13] <Saviq> mhr3, isn't canned query supposed to have all that?
[11:14] <mhr3> Saviq, yes, sure
[11:14] <Saviq> tsdgeos, for now, yes
[11:14] <Saviq> mhr3, dash will have to become a handler for scope:/// anyway
[11:15] <Saviq> mhr3, you already added processQuery()
[11:15] <tsdgeos> Saviq: damn, this means i have to implement all that in the fake plugin scope :D
[11:15] <Saviq> tsdgeos, or convince mhr3 to what I'm saying above ;)
[11:15] <mhr3> Saviq, true
[11:15] <mhr3> so far i'm not convinced either way
[11:15] <mhr3> give me a reason why is it a good idea
[11:16] <Saviq> mhr3, I feel it's a bit unexpected for us to activate and then get back a scope
[11:16] <Saviq> mhr3, the dash knows about scopes, it should handle them itself
[11:16] <Saviq> mhr3, so it can prepare
[11:16] <Saviq> mhr3, otherwise we'll have to give you the query just so that you pass it back up to us (in the form of a scope)
[11:18] <tsdgeos> honestly in this case i'd just like to have a scope_id i can use
[11:18] <tsdgeos> the only thing i'm going to do is open the scope
[11:18] <mhr3> Saviq, feels like you assume you always know the canned query up front
[11:18] <mhr3> but what if you don't
[11:18] <Saviq> mhr3, when don't I?
[11:18] <mhr3> activating preview action perhaps?
[11:19] <Saviq> mhr3, you can come back to me with "open canned query"
[11:19] <Saviq> and pass the query back
[11:19] <Saviq> mhr3, even easier for you, it can come through url dispatcher
[11:19] <Saviq> mhr3, but really, the button should just come with the canned query
[11:19] <mhr3> true
[11:20] <mhr3> Saviq, but tbh i don't see much of a difference really, if i give you just uris all the time you will anyway have to go and ask something - give me a scope object for this
[11:21] <tsdgeos> ok
[11:21] <Saviq> mhr3, sure, but I will expect it
[11:21] <tsdgeos> let's not change stuff for the moment
[11:21] <tsdgeos> let's do the activate + openscope
[11:21] <Saviq> tsdgeos, yeah, I agree let's go with what we have now
[11:22] <mhr3> Saviq, so it's previews all over again? :)
[11:22] <Saviq> mhr3, anyway, I will need the case where I get the query and you don't know anyway, through url-dispatcher
[11:22] <Saviq> mhr3, what about previews?/
[11:22] <mhr3> Saviq, reminded me of the switch from "maybe you'll get a preview back, maybe not"
[11:23] <mhr3> to.. whatever we have now :)
[11:23] <Saviq> mhr3, yeah exactly ;)
[11:23] <mhr3> Saviq, bottomline, i'm fine if you want it changed, not much of a difference from my pov
[11:24] <Saviq> mhr3, I think there's one important thing that might happen
[11:24] <greyback> Saviq: hey dude, seen bug 1340412 ?
[11:25] <Saviq> greyback, ouch
[11:25] <Saviq> mhr3, is that when there's a canned query for a favourite, I don't think we'll be going back to the dash with it
[11:26] <Saviq> mhr3, at which point you'd in the plugin suddenly have to know where the query came from
[11:26] <Saviq> which I don't think you want to
[11:26] <greyback> Saviq: it was fine about 10 days ago, I don't think I've updated manta since
[11:27] <Saviq> greyback, we'll have to bisect images
[11:27] <Saviq> I
[11:27] <Saviq> 'll try and get some time for it somewhen
[11:28] <mhr3> Saviq, right, as i said, can change, give me new api, can implement it
[11:28] <Saviq> mhr3, k
[11:28] <greyback> Saviq: ta
[11:29] <Saviq> mzanetti, would you have some time to review https://code.launchpad.net/~saviq/unity8/drop-filtergrid/+merge/226415 ?
[11:31] <mhr3> gawd
[11:31] <mhr3> miso      2179  1.5  0.0      0     0 ?        Zsl  11:43   0:43 [unity8] <defunct>
[11:31] <mhr3> started by upstart ^^
[11:31] <mhr3> what's one thing that init daemon is supposed to do?
[11:31] <mhr3> can't be collecting zombies right?
[11:32] <mzanetti> Saviq: yes
[11:32] <MacSlow> Saviq, in the latest jenkins-run of the unity8-combo-button-support branch all notification-related qml- and AP-tests pass... only the unrelated testDashContent fails (https://code.launchpad.net/~macslow/unity8/combo-button-support/+merge/221499)
[11:33] <mhr3> one thing it does do well, is crashing your session if things go wrong
[11:33] <MacSlow> Saviq, I really don't know what more I can do to get it past jenkins
[11:35] <Saviq> MacSlow, "Segmentation fault"
[11:35] <Saviq> MacSlow, qmltestrunner segfaults on you
[11:35] <Saviq> MacSlow, but it's obviously not your fault
[11:35] <Saviq> MacSlow, so it's ok, we'll have to spend some time to fix DashContent outside
[11:36] <MacSlow> Saviq, ok
[11:36] <Saviq> MacSlow, I'll kick jenkins again to see if it's actually triggered by your branch, but I rather doubt it
[11:37] <MacSlow> Saviq, btw... I can't start unity8 on the desktop anymore... not sure if you saw my earlier remark here.
[11:37] <Saviq> MacSlow, wait for it... bug #1340086
[11:37] <Saviq> MacSlow, give it 30s
[11:38] <Saviq> mzanetti, I'm adding tests, almost there, but those can be reviewed separately
[11:38] <mzanetti> ack
[11:38] <MacSlow> Saviq, I gave it several minutes... it just spewed out some errors regarding a scope on the terminal
[11:39] <Saviq> MacSlow, hmm then different
[11:40] <MacSlow> does anybody else see this on their desktop-systems... rfkill spams my kern.log with "input handler enabled/disabled" messages.
[11:40] <Saviq> mhr3, does http://pastebin.ubuntu.com/7779635/ sound like anything interesting to you?
[11:40] <Saviq> MacSlow, try "restart scope-registry" and "restart smart-scopes-proxy"
[11:41] <mhr3> Saviq, saw that somewhere already, restart session
[11:41] <Saviq> oops he just did...
[11:41] <mhr3> auto-restart by upstart iguess ^
[11:42] <Saviq> MacSlow, sounds like you lost your session, according to mhr3 that should've helped with the scopes
[11:42] <MacSlow> Saviq, indeed :)
[11:43] <mhr3> sometimes i wish there was "OMG FIX NOW" severity in lp
[11:43] <tsdgeos> Saviq: any clue what should happen when you press the "Back" button on the non favorite scope i just opened from the overview? Back to overview or dash?
[11:44] <tsdgeos> mhr3: that's what critical should be no?
[11:44] <Saviq> tsdgeos, back to overview
[11:44] <mhr3> tsdgeos, for the cases when critical is not enough :)
[11:44] <tsdgeos> Saviq: ok
[11:44] <Saviq> mhr3, you mean bug #1222705
[11:44] <mhr3> that one exactly
[11:45]  * Saviq bumps
[11:46] <MacSlow> Saviq, mhr3: phew... finally unity8 runs again.
[11:47] <Saviq> mhr3, thanks for the facepalm fix for theme inherit
[11:48] <mhr3> Saviq, lucky guess tbh :)
[11:48] <mzanetti> Saviq: so what's happening in that drop-filtergrid branch is that you only set the height of the normal grid and let the cacheBuffer work, right?
[11:49] <Saviq> mzanetti, yes, we're letting the views do delegate handling
[11:49] <mzanetti> Saviq: which also means that we have more delegates in memory now thought
[11:49] <Saviq> mzanetti, right now result is we're actually creating more (since cacheBuffer is > 0 by default)
[11:49] <mzanetti> Saviq: not saying this is necessarily bad
[11:49] <Saviq> mzanetti, but we can tweak that
[11:49] <mzanetti> but yeah, its changed
[11:50] <Saviq> mzanetti, is why I needed to update autopilot
[11:50] <Saviq> mzanetti, but I think that's fine
[11:50] <Saviq> mzanetti, it should help expansion if the first row of items is created already
[11:50] <mzanetti> I don't really see a big problem either... just wanted to have that discussion...
[11:50] <mzanetti> so yeah, we might want to experiment a bit with the cacheBuffer here still
[11:51] <davmor2> mhr3: there is,  It's called "Is it nearly fixed yet bot" you trigger it with !bug_123456_is_it_nearly_fixed_yet mhr3 and it will ping you every minute till the bug say fix committed :)  you just need to make the bot :D
[11:51] <Saviq> mzanetti, truth be told we might set it to 0
[11:51] <mzanetti> that would match previous behavior, yes
[11:51] <Saviq> mzanetti, not exactly
[11:51] <Saviq> mzanetti, another row still will get created
[11:52] <mhr3> davmor2, uuuuh... i want that bot now :)
[11:52] <mzanetti> Saviq: right... even 0 creates 1 row...
[11:52] <mzanetti> Saviq: I vote for setting it to 0 then
[11:52] <Saviq> mzanetti, k, doing
[11:53] <Saviq> oh no cacheBuffer on VJ
[13:22] <elopio> tsdgeos: I solved the conflicts on my unity branches, and all the tests I touched are now passing.
[13:22] <elopio> can you take another look please?
[13:23] <tsdgeos> i'll try to find time
[13:23] <tsdgeos> tbh all i did was check if it merged or not
[13:26] <Saviq> tsdgeos, focus on the overview, we'll handle this
[13:27] <tsdgeos> ok
[13:28] <Saviq> MacSlow, see, it passed now ;)
[13:28]  * MacSlow does the happy-wiggle-dance
[13:45] <tsdgeos> Saviq: "Long press: Opens scope preview (normal theme)" in the "all" part
[13:46] <tsdgeos> does it replace everything (including the header and the done) ?
[13:46] <tsdgeos> also the normal theme is going to look weird
[13:46] <tsdgeos> i guess yes for the first
[13:46] <Saviq> tsdgeos, yeah, it just slides in as usual
[13:47] <tsdgeos> sad thing it's there's no previewlist to slide in anymore
[13:47] <tsdgeos> i have to add another one :D
[13:47] <Saviq> tsdgeos, well, shouldn't there be one in the overview simply?
[13:47] <tsdgeos> sure
[13:48] <tsdgeos> but before we had one for everything
[13:48] <tsdgeos> i could be using here
[13:48] <Saviq> tsdgeos, yeah, well
[13:48] <Saviq> tsdgeos, truth be told we need a stack
[13:48] <Saviq> tsdgeos, and just push / pop as needed
[13:48] <Saviq> tsdgeos, but I don't want to implement a stack myself...
[13:48] <Saviq> but then bug #1247865 :|
[13:49] <tsdgeos> Saviq: also when it says "normal theme"
[13:49] <tsdgeos> it means "non dark"
[13:49] <tsdgeos> right?
[13:53] <Saviq> tsdgeos, yeah
[13:53] <tsdgeos> that looks really bad
[13:53] <Saviq> tsdgeos, I know ;)
[13:53] <Saviq> tsdgeos, I really disagree with all the dark → light → dark → light transitions all this causes
[13:54] <Saviq> tsdgeos, we should only go "up" to overview and back "down" out of it
[13:55] <Saviq> tsdgeos, but since they didn't explore it all visually
[13:55] <Saviq> tsdgeos, we need to show them :|
[13:55]  * tsdgeos forsees a hud
[13:55]  * tsdgeos wants to ru
[13:55] <tsdgeos> n
[13:56] <tsdgeos> running while sitting is quite hard
[14:02] <Saviq> tsdgeos, I don't think it's going to be as bad
[14:03] <Saviq> tsdgeos, I just think they will have to reconsider this and that
[14:03] <Saviq> tsdgeos, like preview in overview → in dark theme
[14:03] <Saviq> tsdgeos, opening a scope always going back "down" first
[14:05] <mhr3> tsdgeos, iirc previews shouldn't be opened from the overview
[14:05] <Saviq> mhr3, yes, for scopes
[14:05] <tsdgeos> mhr3: well you iirc wrong :D
[14:06] <Saviq> mhr3, https://sites.google.com/a/canonical.com/unity8dash/scopes/dash-overview
[14:06] <tsdgeos> or the document is outdated
[14:06] <Saviq> mhr3, "Long press: Opens scope preview (normal theme)"
[14:06] <Saviq> mhr3, in All
[14:08] <mhr3> hmm
[14:09] <mhr3> iri then i guess
[14:09] <mzanetti> Saviq: would it be possible/ok to make tryDashContent show some corner cases? For instance having one scope that has just one category (so we can see/test its not expandable and expanded by the beginning etc)
[14:09] <mhr3> I Recall Incorrectly ;)
[14:09] <Saviq> mzanetti, I pushed the test for that
[14:10] <Saviq> mzanetti, GenericScopeView::test_forced_category_expansio
[14:10] <Saviq> n
[14:10] <mzanetti> Saviq: yeah, I meant more the try thing
[14:10] <mzanetti> but ok...
[14:10] <Saviq> mzanetti, well, it's there already
[14:10] <Saviq> mzanetti, in tryDash
[14:10] <Saviq> mzanetti, and well, tryDashContent, too, it's the last scope on the right
[14:10] <mzanetti> Saviq: I don't see a scope with just one category there
[14:10] <Saviq> mzanetti, build?
[14:10] <mzanetti> hmm.
[14:10] <mzanetti> me looks again
[14:11] <mzanetti> aha... sorry for the noise
[14:11] <mzanetti> didn't rebuild after pulling indeed
[14:11] <karni> mhr3: can u haz look? http://paste.ubuntu.com/7780376/
[14:11] <karni> mhr3: this is on a precise desktop
[14:12] <mhr3> karni, first, i guess you mean trusty?
[14:12] <karni> mhr3: utopic
[14:12] <karni> mhr3: heh, sorry
[14:13] <Saviq> phablet?
[14:13]  * Saviq smells hardcoding
[14:13] <karni> no, desktop, utopic
[14:13] <karni> http://paste.ubuntu.com/7780381/
[14:13] <mhr3> karni, click related
[14:14] <karni> usually up to date every 3 days or so, I did dist-upgrade today and this happened
[14:14] <mhr3> nothing to do with scopes really
[14:14] <karni> mhr3: even though I see libunity-scopes-dev and unity-plugin-scopes ?
[14:14] <mhr3> yes
[14:19] <Saviq> mhr3, are you "unpacking" background values in customization too? like color:/// gradient:/// ?
[14:20] <mhr3> Saviq, am i unpacking them anywhere?
[14:20] <Saviq> mhr3, well, I'm getting { type: "gradient" } and stuff for the card background
[14:21] <mhr3> Saviq, aaah, right... yea, no i'm not
[14:21] <Saviq> mhr3, I agree that's not ideal...
[14:21] <Saviq> mhr3, so maybe I'll just take care of it here...
[14:24]  * Saviq is spewing branches like crazy today
[14:24] <Saviq> mhr3, https://code.launchpad.net/~saviq/unity8/initial-see-all/+merge/226469
[14:27] <mhr3> Saviq, is setting height to 0 the preferred way to hide something? i thought setting visible to false is better
[14:28] <Saviq> mhr3, doesn't work for things using childrenRect
[14:28] <karni> mhr3: coolio, purging of /opt/click.ubuntu.com/.click/users/ solved the problem
[14:28] <Saviq> mhr3, and also, gradients are children of this component, would be hidden, too
[14:28] <Saviq> mhr3, don't get me wrong, that's not ideal
[14:28] <Saviq> mhr3, that's just the least changes
[14:29] <mhr3> k
[14:29] <mhr3> karni, cool
[14:29] <tsdgeos> Saviq: the card creator doesn't know how to do cards like the ones in the overlay i just realized
[14:29] <mikenagle> saviq - you're dead right but the spec says:  Note, this interaction is disabled on:
[14:29] <mikenagle> Search screen
[14:29] <mikenagle> Preview screen
[14:29] <mikenagle> Installed, non favourite scopes opened from the overview screen
[14:29] <tsdgeos> art + title + overlay with the title centered
[14:30] <mikenagle> saviq, tsdgeos - re the overview spec - you can ignore the comments - they just reflect the conversation that got us to the spec :)
[14:31] <facundobatista> I'm not being able to create properly an emulator instance: http://pastebin.ubuntu.com/7780434/  do you have any idea where I can find logs to see what's going on? (btw, I'm in Utopic)
[14:31] <Saviq> mikenagle, still, I think you'll need to reconsider a few things, ideall with transition videos
[14:31] <Saviq> mikenagle, I really feel like having both dark (overview) and light (everything else) "elements" on the same level is going to be confusing
[14:31] <tsdgeos> mikenagle: ok
[14:31] <Saviq> mikenagle, and since you can only preview scopes in the overview, why not show them in the dark theme?
[14:32] <Saviq> tsdgeos, it does, only we can't change the overlay colour yet
[14:32] <Saviq> tsdgeos, and the "centered text" part I believe is a bug actually ;P
[14:32] <tsdgeos> erg
[14:32] <tsdgeos> ok :D
[14:33] <mikenagle> saviq - the scopes are never dark though - just the space around them is dark. Scopes themselves will be any colour the author/brand needs
[14:33] <mikenagle> saviq (of course a dark branded scope will be dark but you know what I mean :))
[14:33] <tsdgeos> mikenagle: but you are going from "All" to "preview of scope XYZ"
[14:33] <Saviq> mikenagle, I mean that as you long-press a scope in the All category, you'll open a preview for that scope
[14:33] <tsdgeos> "all" is dark
[14:33] <tsdgeos> "preview of scope XYZ" should be dark too
[14:33] <Saviq> tsdgeos, ↑
[14:33] <Saviq> eee
[14:33] <Saviq> mikenagle, ↑↑
[14:34] <Saviq> mikenagle, preview of scope is part of the scopes scope / overview
[14:34] <Saviq> not of the dash
[14:36] <mikenagle> saviq tsdgeos. Gotcha. You might be right. Hard to say without testing. But Esti and I tihnk to keep it light for the time being at least
[14:36] <mikenagle> saviq tsdgeos. As soon as there's a build to look at though, shout and I'll take another look to check I'm not crazy :)
[14:37] <mhr3> Saviq, the see all seems too big
[14:37] <mhr3> Saviq, or its font size too small
[14:38] <Saviq> tsdgeos, something along the lines of http://pastebin.ubuntu.com/7780453/
[14:39] <tsdgeos> Saviq: yeah yeah sorry
[14:39] <tsdgeos> ignore me
[14:39] <tsdgeos> :D
[14:39] <Saviq> tsdgeos, obviously missing overlay colour
[14:39] <tsdgeos> it's just that i think we the centering is not really really centered
[14:39] <tsdgeos> looks a few pixels off
[14:40] <mhr3> Saviq, also, some weirdness - http://imgur.com/J4DT6Fn
[14:40] <tsdgeos> which actually makes sense
[14:40] <tsdgeos> as http://paste.ubuntu.com/7780461/
[14:40] <tsdgeos> has left margin and not right one
[14:40] <mhr3> Saviq, that was after expand + collapse
[14:43] <Saviq> tsdgeos, yup, that's what I thought
[14:44] <tsdgeos> Saviq: yeah adding the margin looks better now
[14:44] <Saviq> mhr3, hmm and not like that with in-header expansion?
[14:45] <Saviq> mhr3, as for sizing, I took what Joshua sent me as "redlines"
[14:46] <mhr3> Saviq, sorry? what do you mean with in-header expansion?
[14:47] <mhr3> as for sizing... ok if design said so...
[14:48] <Saviq> mhr3, that you couldn't get that weirdness before "see all"
[14:48] <Saviq> mhr3, and well, can you repro? I can't
[14:48] <mhr3> Saviq, nope haven't seen that before, but you're right i can't repro it now either
[14:49] <Saviq> shipit!
[14:49] <mterry> kgunn, Saviq: for emergency dialer, two branches need review from our side: https://code.launchpad.net/~mterry/unity8/is-active/+merge/223653 and https://code.launchpad.net/~mterry/unity8/dialer-above/+merge/224947  -- the first is ready to go, I'm fixing a merge conflict in the second right now
[14:49] <mterry> And the second needs a security pass
[14:50] <mterry> mdeslaur, ^ do you or sarnold have time to look at that dialer-above branch sometime?
[14:51] <mhr3> Saviq, btw noticed how horrible does wikipedia logo look on desktop?
[14:51] <Saviq> mhr3, yeah, on cards?
[14:52] <mhr3> Saviq, logo
[14:52] <Saviq> mhr3, so just the W, or WikipediA in the header?
[14:52] <Saviq> mhr3, in any case
[14:52] <Saviq> mhr3, prolly no sourceSize
[14:52] <kgunn> mterry: thanks for the follow up
[14:52] <Saviq> mhr3, initctl set-env -g GRID_UNIT_PX=11
[14:53] <Saviq> doesn't really help ;)
[14:53] <mterry> kgunn, my understanding is that there is a second pass from dialer side for other UI things (like adding a cancel button and going fullscreen and such)
[14:53] <mhr3> Saviq, i need to wait a minute for unity to run again :P
[14:54] <kgunn> mterry: good to know...but nothing stopping us ?
[14:54] <mterry> kgunn, which reminds me...  they'll need https://code.launchpad.net/~mterry/unity8/show-greeter-dbus/+merge/224942 for the cancel support
[14:54] <mdeslaur> mterry: sometime, yes :)
[14:54] <Saviq> mhr3, sudo rm /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Telephony/qmldir
[14:54] <mterry> kgunn, no, their second pass doesn't stop us from doing our side
[14:55] <mhr3> Saviq, \o/ and yea still looks horrible
[14:55] <Saviq> mhr3, huh! sourceSize is set (albeit * 4 for some reason)
[14:55] <Saviq> mhr3, the icon must be something weird
[14:55] <mhr3> strangely, it's fine on the phone
[14:55] <Saviq> mhr3, told you we can't render SVGs :P
[14:56] <Saviq> mhr3, they all look rather bad
[14:57] <mhr3> wait whaat... is doesn't look good on the phone
[14:57] <mhr3> s/is/it/
[14:57] <mhr3> but i remember it looking fine
[14:59] <mhr3> Saviq, also, they're all pngs :P
[15:00] <Saviq> mhr3, oh now that's interesting
[15:00] <Saviq> mhr3, are they named @30 or something?
[15:00] <Saviq> mhr3, or are they remote?
[15:00] <mhr3> Saviq, yep, remote
[15:00] <mhr3> https://dash.ubuntu.com/imgs/logos/header-logo-wikipedia.png
[15:01] <Saviq> mhr3, that looks fine here, I thought you were asking about the ones in scopes scope
[15:01] <Saviq> well, ok, maybe not really fine, blurred a bit they are
[15:02] <mhr3> they are frickin huge!
[15:02] <mhr3> especially wiki
[15:02] <mhr3> it's not supposed to be that big
[15:03] <Saviq> mhr3, well, pad them!
[15:04] <Saviq> mhr3, how am I supposed to know how big you want them
[15:04] <Saviq> or how aligned
[15:05] <mhr3> i thought they are, but apparently not
[15:05] <mhr3> anyway, not sure why i'm bothering you with that... esti / facundobatista issue
[15:06] <facundobatista> mhr3, sorry?
[15:06] <mhr3> facundobatista, http://imgur.com/xMUwWvn <-- eeek
[15:08] <facundobatista> mhr3, you say it should be smaller?
[15:08] <mhr3> facundobatista, shouldn't it?
[15:09] <facundobatista> mhr3, IMO, the server should provide a bigger enough one, and the client should scale to what's needed... otherwise how do we manage for bigger phones, or tablets, or whatever?
[15:10] <facundobatista> mhr3, I mean, if I rescale it in the server, then may be too small for other clients
[15:12] <facundobatista> mhr3, actually... thinking better about it, the server should provide .svg only, and client present it in the optimal size
[15:13] <mhr3> facundobatista, svg/png doesn't matter really, as you said the resource will be presented on devices with various res, the icons should have padding to look good
[15:14] <mhr3> ie the image should be done in a way to fit the full header height
[15:15] <mhr3> facundobatista, right now they seem to be cropped to content
[15:17] <mhr3> facundobatista, wait, did something happen with the images?
[15:17] <facundobatista> mhr3, what?
[15:17] <mhr3> facundobatista, the ones joshua sent did indeed have padding
[15:17] <facundobatista> let me see
[15:17] <mterry> Do the unity8 qmluitests pass for other people?  I'm seeing an error on test_purchase_text_display
[15:17]  * facundobatista searches joshua's mail
[15:22] <facundobatista> mhr3, I have a mail from joshua from June 26th, with header logos for several scopes
[15:22] <facundobatista> mhr3, is that what you mean?
[15:22] <mhr3> facundobatista, june 16th
[15:23] <mhr3> is the one i'm looking at
[15:23] <facundobatista> mhr3, ah, he then sent another one, updated images
[15:24] <mhr3> facundobatista, then i guess the second one breaks things?
[15:24] <facundobatista> mhr3, probably! I just forwarded it to you
[15:24] <facundobatista> well, it's being sent (the attached zip is 2MB)
[15:25] <facundobatista> mhr3, probably a couple of instructions or conditions should be given to Joshua when he buiilds the images
[15:25] <mhr3> not the first time i see designers sending two email and each is done fundamentally differently
[15:29] <mhr3> facundobatista, yea, they're wrong
[15:29] <facundobatista> :/
[15:30] <mhr3> facundobatista, can you reply to joshua that the logos need to have the padding to fit the entire height of the header?
[15:30] <mhr3> show him http://imgur.com/xMUwWvn to understand the issue
[15:32] <mhr3> although.. that isn't entire height
[15:32] <mhr3> there is a little bit of padding
[15:33] <facundobatista> mhr3, sent
[15:35] <mhr3> yea, 1gu margin on top and bottom
[15:54]  * greyback eow
[16:40] <kgunn> arrgg mterry where u be?
[16:57] <Saviq> enough
[16:57] <Saviq> o/
[18:31] <kgunn> mterry: hey quick little brainstorm about mir & debian deps  in control files
[18:31] <mterry> kgunn, hi
[18:32] <kgunn> so, thinking today our rverse deps all say >=mir version
[18:32] <kgunn> but, as we're about to branch for rtm....that's not gonna work well
[18:32] <kgunn> e.g. chance exists we may need to break abi on server even after branching
[18:33] <mterry> kgunn, you're thinking you want a dep on mir << version+1?
[18:33] <kgunn> but...could end up with 2 diff versions progressing, 1 on stable-rtm and 1 on trunk
[18:33] <kgunn> well...that;s just it...i'm thinking =
[18:33] <kgunn> exact
[18:33] <kgunn> i mean, we never skip building reverse depends anyway
[18:34] <kgunn> so in reality we're saying = even tho control says >=....which >= isn't true (e.g. abi is broken)
[18:35] <kgunn> so i just want to verify my thinking we should change the control files in u-s-c, papi, unity-mir
[18:35] <mterry> kgunn, well it's sort of true, but yeah we should have << next-abi-version
[18:35] <mterry> kgunn, as for addressing two different version tracks...
[18:35] <kgunn> yeah, i thot about that, but that's not true either right ?
[18:35] <mterry> kgunn, how about defining a version prefix that is used for the branch.  Like 4.5.  Then have trunk move past that, doing 5.x and what not.  But ABI breaks on branch can go like 4.5.1, 4.5.2 or whatever?
[18:35] <mterry> kgunn, why wouldn't it be?
[18:36]  * kgunn erases next chat, and goes to read debian again
[18:37] <mterry> kgunn, you could always ABI-version the -dev packages too...  So that you have libmirserver18-dev
[18:37] <kgunn> mterry: right...so we'll end up with interleaving (potentially) mir versions
[18:38] <mterry> kgunn, well we'd ideally avoid interleaving.  You could set the branch to 4.5 and have it live in that namespace forever.  While trunk immediately bumps to 4.6 or something and never looks back
[18:38] <kgunn> e.g. imagine stable goes 0.5, 0.7, 0.9...and trunk goes 0.6, 0.8, 0.10
[18:38] <mterry> kgunn, yeah well don't do that on stable.  Have stable live in 0.X and trunk live in 1.x (like we did for unity8)
[18:39] <kgunn> but if x in 0.x.0 is referencing abi breaks...then what happens if we have a bug fix on stable that breaks abi
[18:40] <mterry> kgunn, right, you just have to "shift down" your expectation of what an abi break is one digit place
[18:40] <kgunn> (its not hypothetical....we just found something that would bump it, had we found it 2 weeks in the future after Beta freeze)
[18:40] <mterry> kgunn, so now if "0.x" is your branch indicator, then "0.x.y" is your abi and "0.x.y.z" is your minor bug fix bumps
[18:41] <mterry> kgunn, and maybe use libmirserver18.x etc
[18:41] <mterry> where 18 is the major version we use for stable
[18:44] <kgunn> mterry: how does that fit or change debian control in rdeps if stable had libmirserver18, 20, 22....and trunk might end up with libmirserver19, 21, 23
[18:44] <kgunn> ?
[18:45] <kgunn> hmm...actually....if its truly ABI...am i worrying about nothing ?
[18:45] <kgunn> the rdeps could really still compile
[18:45] <mterry> kgunn, well I think this whole thing is very similar to unity7 vs unity8.  We give the stable version a major version like...  22.  And then it lives there and we'd have libmirserver22.1 and libmirserver22.2 for ABI bumps
[18:45] <kgunn> only if its server API....then its an issue
[18:46] <mterry> kgunn, any time we need to fork a stable branch, we just freeze the major version it was on (22 or 38) and have trunk move on
[18:53] <kgunn> mterry: is that really by convention ? or a technical rule that breaks some enforcement ?
[18:53] <kgunn> understand its ideal
[18:53] <mterry> kgunn, most of these version rules are by convention
[18:53] <kgunn> ack
[18:54] <mterry> kgunn, but I was just trying to suggest a scheme that would avoid having stable be above trunk but still be able to move inside its own version namespace
[18:54] <kgunn> mterry: i'll pursue the idea of decoupling
[18:56] <mterry> kgunn, other schemes would be fine too if you had a different idea in mind.  But I think (a) your point that we are missing an upper bound on deps is valid -- we should use << next-abi-version and (b) as long as we can have stable and trunk moving in their own abi namespaces, we're good
[18:57] <kgunn> mterry: hmmm, i just can't get around the fact we're trying to tie rdeps to server api bumps basically...
[18:57] <kgunn> i'll keep thinking
[18:57] <mterry> kgunn, isn't that a good thing?
[18:58] <kgunn> mterry: it is, and they're just numbers....
[18:59] <mterry> kgunn, what are you getting at?
[19:00] <kgunn> so in theory it could do that....stable 0.4.0 turns into 0.4.1.0, 0.4.2.0, 0.4.3.0, 0.4.4.0....and then trunk goes 0.5.0.0, 0.5.1.0
[19:00] <kgunn> or could trunk stay 0.5.0, 0.6.0
[19:00] <kgunn> ....until the next stable
[19:01] <kgunn> so in 0.x.y.z the y means...abi bumps on stable
[19:01] <mterry> kgunn, sure, trunk could keep going crazy until we need to fork again
[19:01] <kgunn> lol
[19:01] <kgunn> mterry: with the hopes that someday we get the server api under control
[19:02] <mterry> kgunn, I'm a big fan of bumping major versions whenever we need.  I think deja-dup is on version 32 or something
[19:02] <mterry> kgunn, well even if server abi doesn't change, doesn't mean that the project version couldn't.  but sure, it would be nice to have that move slower
[19:03] <kgunn> mterry: at the end of the day...there's going to be 2 diff control files as well in each of the rdep projects...trunk for trunk & stable for stable
[19:04] <kgunn> hence my reasoning in the beginning its really an = situation
[19:04] <mterry> kgunn, yup, I don't think there's a way around that which we would find acceptable
[19:04] <mterry> kgunn, no, but we don't want =
[19:04] <mterry> kgunn, because we do actually release the occasional bug fix
[19:04] <mterry> kgunn, we just want >= abi and << abi+1
[19:05] <mterry> kgunn, or really
[19:05] <kgunn> right so with the proposal above we can keep it >=, with trunk staying 0.x.x and stable being 0.x.x.x
[19:05] <mterry> kgunn, regardless of how we split trunk and stable, I still think it's sensible to do <<abi+1 for both
[19:06] <kgunn> mterry: sorry to be thick skulled...but that's not really true...i mean we do really break api on server sometimes too
[19:06] <kgunn> so that wouldn't be completely true
[19:06] <mterry> kgunn, I mean, it's mostly taken care of magically for the binary package dependencies, because the abi is encoded in the package name (so libmirserver18 >= 4 implies that it doesn't match libmirserver19).  But it matters for the -dev packages which don't encode abi in package name
[19:07] <kgunn> so are you saying to ignore the logic and rely on the magic ? ;P
[19:07] <mterry> kgunn, I don't follow your pointn about breaking api on server?  You mean api vs abi?
[19:08] <mterry> kgunn, we could mostly.  -dev dependencies don't care about ABI, just API breaks
[19:08] <mterry> kgunn, but this all is a separate point from how to split the versioning for stable/trunk
[19:08] <mterry> kgunn, I was just proposing a separate nice fix to use <<abi+1 but I think we don't really need that for any of the packages I can think of
[19:09] <kgunn> ok...i'm gonna copy.paste this irc chat and share with cemil/duflu
[19:09] <mterry> We could do it for the -dev packages, but we don't have a versioning scheme for breaking API
[19:10] <mterry> kgunn, I think my takeaway is just to suggest freezing stable's major version and bumping down the ABI position by 1 place so as not to conflict with trunk
[19:23] <kgunn> mterry: one last question...so for libmirserver<somenumber>....assuming stable is mir0.5.y.z, and trunk is mir0.6.y
[19:23] <kgunn> can the number of libmirserver<number> be the same and sage ?
[19:23] <kgunn> oops/sage/safe
[19:24] <mterry> kgunn, well.  the versions like 0.5/0.6 *could* safely be the same too.  Because they'd be in different repositories.  But that way lies massive confusion.  So I'd say the same for the libmirserverXX numbers
[19:25] <kgunn> yeah
[19:25] <kgunn> agreed...i don't like it either
[22:03] <Saviq> mzanetti, if you're around, is there a reason why we don't have a ubuntu-touch package in silo 6?