[08:35] <seb128> Saviq, hey, do you know what's the status of https://bugs.launchpad.net/canonical-devices-system-image/+bug/1393438? is the fix on that bug supposed to address the issue? where is the translatable string in that case?
[08:36] <Saviq> seb128, digging...
[08:37] <Saviq> seb128, right, so it's missing some work on our (unity8) side
[08:37] <seb128> Saviq, k, that explains, thanks
[08:38] <seb128> Saviq, any chance that get assigned to somebody? the string is quite visible in the ui
[08:38] <Saviq> seb128, just did
[08:38] <seb128> thanks
[09:21] <seb128> Saviq, sorry to have reported that dialer bug against unity8, I was unsure what component to pick, it's a bit of an app management issue ... could be the job from whoever started it to close it, or could be up to the dialer to exit after call
[09:21] <Saviq> seb128, no worries, I left a unity8 task just in case
[09:22] <Saviq> as it's indeed not clear dialer can do all it needs to do
[11:04] <Cimi> tsdgeos, testing the temp scope to temp scope is a bit tricky: the only scope calling activate is the click scope, but the click scope cant be made unfavourite
[11:06] <tsdgeos> Cimi: so what's the real world scenario we are fixing?
[11:07] <tsdgeos> it's store as temp, and then a preview in store calling another temp, no?
[11:10] <Saviq> Cimi, the store scope calls activate too
[11:10] <tsdgeos> if that's what we're having
[11:10] <Saviq> Cimi, you go to store, install a scope, press Search
[11:10] <tsdgeos> we should try to replicate something similar
[11:11] <tsdgeos> it doesn't need to be "the store" in our mocks
[11:11] <tsdgeos> but something similar to what we're fixing
[11:11] <tsdgeos> so the test is at least the real world case
[11:11] <Cimi> we're fixing temp scope from tempo scope
[11:12] <tsdgeos> Cimi: via what? preview or just activation of a result?
[11:13] <Cimi> tsdgeos, for now preview, but I guess we need to see other possible scenarios
[11:13] <tsdgeos> sure
[11:13] <Cimi> in the test I am manually calling activate
[11:13] <tsdgeos> yeah
[11:13] <Cimi> from a temp scope
[11:13] <tsdgeos> don't do that
[11:13] <tsdgeos> let's please make a test that does the same the user does
[11:14] <Cimi> but how do I create a ubuntu store scope with previews?
[11:14] <tsdgeos> it doesn't need to be a ubuntu scope
[11:14] <tsdgeos> it can be any of the mock scopes
[11:14] <tsdgeos> and they have previews already
[11:15] <tsdgeos> you just need to make one of those previews be special and do the same the store scope does to us when pressed
[11:15] <Cimi> yeah, don't know what it does
[11:16] <Cimi> have to dig
[11:19] <Cimi> where is the code of the store?
[11:19] <tsdgeos> you don't need the code for the store
[11:20] <tsdgeos> just add some console.log in the preview code
[11:20] <tsdgeos> and see how what it does
[11:21] <tsdgeos> triggeredAction looks like a good place to add a console log
[11:21] <Cimi> OK
[11:22] <Saviq> /food
[11:45] <Cimi> tsdgeos, it might be that is the preview model launching actions?
[11:47] <Cimi> I see in Preview.qml that the buttons call previewModel.triggered()
[11:47] <Cimi> (with action  open_click [object Object] with the latter probably a scope)
[11:50] <tsdgeos> Cimi: and how does that come back to us? in gotoScope/openScope of Dash.qml/DashContent.qml ?
[11:52] <Cimi> tsdgeos, don't know
[11:54] <tsdgeos> Cimi: console.log!
[12:00] <Cimi> tsdgeos, the action is called by the backend
[12:01] <tsdgeos> of course
[12:01] <tsdgeos> i'm just trying for you to understand the call path
[12:01] <tsdgeos> so you can make our mock do something similar
[14:20] <mzanetti> mterry: hey
[14:20] <mterry> mzanetti, hello!
[14:20] <mzanetti> mterry: I'm trying to fix the as launcher model
[14:20] <mzanetti> mterry: can I know if the session is running?
[14:20] <mzanetti> in order to ignore the non pinned ones
[14:23] <mterry> mzanetti, umm..  I just checked and I actually can't see that in the greeter API that LightDM exposes...
[14:23] <mterry> mzanetti, LightDM surely knows
[14:23] <mterry> mzanetti, but...  oh wait.
[14:23] <mterry> mzanetti, no the greeter does know
[14:24] <mterry> mzanetti, so the greeter can know via liblightdm
[14:24] <mterry> mzanetti, but your branch doesn't care about that side of things, right?
[14:24] <mterry> mzanetti, your branch doesn't actually *use* the AS launcher model?
[14:24] <mzanetti> mterry: not really
[14:25] <mzanetti> mterry: it's just preparing it for you, so you can take it into use without having to mess with the launcher too much
[14:25] <mzanetti> mterry: I've added the pinned information to the sync process now
[14:27] <mzanetti> mterry: so what do you propose?
[14:28] <mterry> mzanetti, let me see if you can do anything with that information, given the current state of the LightDM plugin... hold on
[14:29] <mzanetti> I could add a "hideUnpinned" property to the launcher api. then when you use that in the split greeter, set that to true somehow when the session is not running
[14:29] <mterry> mzanetti, so it is exported via the "loggedIn" data property on the LightDM.UsersModel object
[14:30] <mterry> mzanetti, so that should be simple to hook up to your hideUnpinned property, yeah
[14:30] <mzanetti> ack
[14:51] <greyback> Anyone have an opinion on QQmlListProperty versus QAbstractListModel? I preferred QQmlListProperty for simple lists of objects, but now I think about it, it just has a "list changed" signal - it doesn't inform the view more detail about what changed like QAbstractItemList does (dataChanged, itemAdded/Removed)
[14:52] <mzanetti> greyback: yeah... QQmlListItem is pretty useless unless you want to create/change the list from qml
[14:53] <mzanetti> err. QQmlListProperty
[14:54] <greyback> mzanetti: so I'm seeing. But I never really liked creating a QAbstractListModel with a single roleName either, since the  role is kinda pointless
[14:54] <mzanetti> yeah...
[14:54] <mzanetti> I for one so far always ended up converting my QQmlListProperties into real models at some point
[14:56]  * greyback takes note
[15:15] <tsdgeos> Saviq: Cimi: how do you guys see https://code.launchpad.net/~aacid/unity8/properVRangesCurrentScope/+merge/246465 ?
[15:16] <Saviq> tsdgeos, "see" in what way? it's a Needs-review MP?
[15:16] <tsdgeos> Saviq: yeah
[15:16] <tsdgeos> and i need someone not me
[15:16] <tsdgeos> to check if we actually want that :D
[15:16] <tsdgeos> or not
[15:16] <Saviq> ok, I'll check it out
[15:17] <Cimi> Saviq, thx
[15:18] <pstolowski> Cimi, hey! can we land https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-temp-scopes/+merge/248235 ? did you have a chance to test it with your fix?
[15:19] <Cimi> tsdgeos, today I noticed that when we open or switch to a scope, we load all results then we do collapse
[15:20] <Cimi> pstolowski, seems to work, I am working on unity side
[15:20] <tsdgeos> Cimi: what you mean load all results and then collapse?
[15:21] <Cimi> tsdgeos, try with the kickstarter scope from the store
[15:21] <pstolowski> Cimi, ok, cool
[15:21] <Cimi> tsdgeos, you see the categories start populating, then it collapses
[15:21] <Cimi> it starts expanded then collapse
[15:22] <Cimi> maybe when we load scopes we should load just collapsed results at first, then load the rest later?
[15:23] <paulliu> Seems mumble dies again?
[15:24] <tsdgeos> Cimi: hmmm we load everything collapsed
[15:24] <tsdgeos> or we should
[15:24] <tsdgeos> Cimi: can you record a video?
[15:25] <Saviq> paulliu, yeah, it looks like
[15:26] <Cimi> tsdgeos, ok
[15:46] <Cimi> tsdgeos, https://www.youtube.com/watch?v=RTG6xPYmR48
[15:48] <Cimi> also, this "hide manage dash and scroll right to the scope" isn't the best, but it is more a design thing
[15:49] <Saviq> Cimi, I assigned you to the bug today, the one about "Enable location" being untranslated in our UI, we need to add a special setting type that will have the strings to translate hardcoded
[15:51] <Cimi> Saviq, saw it
[15:51] <Cimi> Saviq, I am still trying to do this test for the temp scope fix
[15:51] <Saviq> Cimi, yeah sure, just wanted to let you know the desired approach
[15:51] <Saviq> Cimi, this looks like we're leaving the first category expanded until there's more categories, which is per design, but I agree the visual glitches are not nice
[15:51] <tsdgeos> Cimi: hmmm, that's weird, we default to non expanded for all categories, does this only happen on that scope or all?
[15:52] <Saviq> tsdgeos, don't we have code that expands if there's only one category?
[15:52] <Cimi> tsdgeos,  noticed only on that scope
[15:52] <Saviq> tsdgeos, Cimi, it might be that the scope registers the categories as they come in
[15:53] <Cimi> it's tedg fault :P
[15:53] <Saviq> instead of early in the reply
[15:53] <tsdgeos> Saviq: hmmmm, can't find anything like that in the code tbh
[15:54] <tedg> Cimi, Me? Temperature? It's nice here, not cloudy London.
[15:54] <Saviq> tsdgeos, GSV.qml:236
[15:54] <tedg> Cimi, Do you even remember what the sun is like anymore? ;-)
[15:55] <Saviq> tsdgeos, and then GSV.qml:307-308
[15:55] <Saviq> tsdgeos, one category == not expandable; == expanded
[15:55] <tsdgeos> Saviq: but it has to match expandedCategoryId
[15:56] <tsdgeos> expandedCategoryId is only set when clicking on see all
[15:56] <Cimi> tedg, morning.
[15:57] <Saviq> tsdgeos, not really, height is selected based on bool expanded, which is always true if bool expandable is false
[15:57] <Cimi> tedg, I forgot :(
[15:57] <tedg> Cimi, You need to come visit!
[15:57] <tsdgeos> ah right right
[15:58] <tsdgeos> Saviq: not expandable means not collapsable either
[15:58] <Saviq> tsdgeos, yup, it's just full-height always
[15:58] <Saviq> tsdgeos, which means that if we're just getting one category, all results, then another category
[15:58] <tsdgeos> yeah i think the code expects the categories not to change on runtime
[15:58] <Saviq> tsdgeos, we load them all just to collapse them again
[15:58] <tsdgeos> yeah
[15:59] <Saviq> yeah, the scope API I'm afraid allows that, if not encourages
[16:01] <Cimi> tedg, will come to see you and evan...
[16:04] <tsdgeos> tedg: Saviq: so on https://code.launchpad.net/~ted/unity8/delay-indicator-start/+merge/241124 ? discard?
[16:05] <tedg> I'm still +1 on it. I think it makes more sense. Doesn't fix that bug, but it should help.
[16:06] <tedg> No reason to make Unity compete for resources.
[16:06] <tsdgeos> mzanetti: any idea why daniel didn't top approve https://code.launchpad.net/~mzanetti/unity8/launcher-fixes/+merge/248761 ?
[16:07] <mzanetti> tsdgeos: he probably just forgot... was sitting next to him when he told me he's ok with it
[16:07] <tsdgeos> is he on holidays this week?
[16:08] <mzanetti> don't think so... I guess having a swap day for travelling across the sea
[16:08] <tsdgeos> ok, let's wait for him tomorrow then
[16:10] <tsdgeos> mzanetti: can you do https://code.launchpad.net/~dandrader/unity8/improveLauncherTests/+merge/248919 alternatively?
[16:10] <mzanetti> tsdgeos: yep, on my list
[16:10] <mzanetti> lemme claim it
[16:10] <tsdgeos> cool
[16:16] <tsdgeos> MacSlow: so where are we on https://code.launchpad.net/~macslow/unity8/swipe-dismiss-snap-decisions/+merge/233347 can you reproduce the errors Saviq mentions?
[16:16] <Saviq> tsdgeos, that seems fixed already, but he's got some other failures
[16:16] <tsdgeos> i see
[16:16] <Saviq> actually a hash sum mismatch for qmluitests, /me rebuilds
[16:17] <Saviq> MacSlow, the ap test for lifecycle is sometimes flaky, don't worry about that
[16:17] <MacSlow> Saviq, I assumed that after a few tries on my machines here
[16:18] <Saviq> MacSlow, just start with kicking a jenkins rebuild next time
[17:25] <mzanetti> mterry: ok. pushed the branch
[17:26] <mzanetti> mterry: didn't change the appid/url thing for the reason of consistency. We use appId all over to identify items... not sure I want to do something else here
[17:27] <mterry> mzanetti, OK makes sense.  Like I said, I was just half-remembering a conversation about that
[17:27] <mterry> mzanetti, will review again, thanks!
[17:37] <mzanetti> mterry: ah, I agree that we should collect split greeter based plugins in the Greeter dir. also that it should be another MP :D
[17:38] <mterry> mzanetti, yeah it's grown beyond a thin layer on top of lightdm
[17:39] <mzanetti> indeed