[07:26] <tsdgeos> mzanetti: Cimi: the Qt crasher has been merged can you re-review https://code.launchpad.net/~unity-team/unity8/two_see_more_bugfix/+merge/234340 ?
[07:27] <tsdgeos> Cimi: and i fixed your comments in https://code.launchpad.net/~aacid/unity8/category_view_invisible_in_preview_mode/+merge/231844 i think
[07:31] <Cimi> morning
[07:32] <tsdgeos> @unity8: comments on my last comment of https://code.launchpad.net/~dobey/unity8/purchase-unprogress/+merge/234747 ?
[07:47] <Cimi> tsdgeos, any idea on https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1370618 ?
[07:47] <Cimi> tsdgeos, is it due to the overvew?
[07:47] <tsdgeos> don't know
[07:48] <tsdgeos> but not worth investing time now that we're killing the overview anyway
[07:49] <Cimi> tsdgeos, if is due to overview, yes
[07:49] <Cimi> tsdgeos, otherwise we will still have it
[07:49] <tsdgeos> if we still have it
[07:49] <tsdgeos> we can have a look then
[07:49] <Cimi> tsdgeos, do you shrink the view when applying the transition effect?
[07:49] <tsdgeos> i do lots of things to the view
[07:50] <tsdgeos> shrinking is not specially one of them afaik
[07:50] <tsdgeos> but it may be in there
[07:50] <Cimi> tsdgeos, so it is likely it, or the usual but of mir not updating the frame
[07:50] <Cimi> we will see
[07:50] <tsdgeos> yep
[07:50] <Cimi> usual bug
[07:57] <tsdgeos> marcustomlinson: looks good now :)
[07:58] <tsdgeos> marcustomlinson: do you think you can bring the
[07:58] <tsdgeos> 137	+ }
[07:58] <tsdgeos> 138	+ else {
[07:58] <tsdgeos> to just
[07:58] <tsdgeos> } else {
[07:58] <tsdgeos> ?
[07:58] <marcustomlinson> tsdgeos: k sure
[07:58] <tsdgeos> cool
[07:58] <tsdgeos> thanks for the patch :)
[07:59] <tsdgeos> i'll wait for CI to run to top approve
[08:01] <marcustomlinson> tsdgeos: cool, pushed
[08:06] <Cimi> tsdgeos, https://code.launchpad.net/~unity-team/unity8/two_see_more_bugfix/+merge/234340
[08:06] <tsdgeos> Cimi: we've always checked id
[08:06] <tsdgeos> no?
[08:07] <Cimi> tsdgeos, I thought we checked item before, no?
[08:07] <tsdgeos> not that i know
[08:07] <tsdgeos> or maybe someone did
[08:07] <Cimi> 62	-        property Item expandedCategoryItem: null
[08:07] <Cimi> 63	+        property string expandedCategoryId: ""
[08:07] <tsdgeos> ah yes
[08:07] <tsdgeos> someone broke it :D
[08:07] <tsdgeos> before people broke it
[08:07] <tsdgeos> i used to check id
[08:08] <tsdgeos> checking item is bad
[08:08] <tsdgeos> because if you scroll a lot and back
[08:08] <tsdgeos> you'll have the item destroyed
[08:08] <tsdgeos> and that's why you have to use id
[08:08] <Cimi> good point
[08:08] <Cimi> tsdgeos, now question is
[08:08] <tsdgeos> just that someone approved the thing without me realizing :D
[08:08] <Cimi> tsdgeos, id is always unique?
[08:08] <tsdgeos> it is
[08:08] <tsdgeos> scopes need that
[08:08] <Cimi> ok, but no ay you can write a scope and crash the dash, right?
[08:09] <tsdgeos> i guess there's millions
[08:09] <tsdgeos> like doing
[08:09] <tsdgeos> int *a = 0; *a = 33; in the code :D
[08:09] <tsdgeos> pstolowski: can you confirm that inside a single scope category id have to be different?
[08:09] <Cimi> tsdgeos, if we do public scopes, that you can install from the store, we need to be sure nothing weird happens
[08:10] <Cimi> tsdgeos, otherwise having scopes in separate processes starts to be a really good idea
[08:10] <Cimi> tsdgeos, so if a bad developer writes a bad scope, unity8-dash is safe
[08:11]  * Cimi just thought of a burger scope with all the best burgers in town
[08:12] <tsdgeos> ;)
[08:16] <tsdgeos> Cimi: fixed https://code.launchpad.net/~unity-team/unity8/two_see_more_bugfix/+merge/234340 again
[08:17] <Cimi> tsdgeos, let's wait for the other comment
[08:18] <tsdgeos> Cimi: which one?
[08:18] <Cimi> tsdgeos, Ids
[08:18] <tsdgeos> ah
[08:18] <tsdgeos> i'm pretty sure that's right
[08:18] <tsdgeos> as i commented there we used to do that
[08:18] <tsdgeos> and it was fixed because someone thought it was better when it was clearly not
[08:19] <tsdgeos> but sure, let's wait for pstolowski
[08:20] <pstolowski> tsdgeos, otp
[09:14] <pstolowski> tsdgeos, yes, categories have to be unique within a single scope
[09:14] <tsdgeos> Cimi: ↑↑
[09:15] <pstolowski> tsdgeos, Cimi and scopes API will reject an attempt to create a category with same id
[09:15] <Cimi> pstolowski, that is what I wanted to her
[09:15] <Cimi> good
[09:16] <Cimi> pstolowski, we have some code checking for id, which could potentially freak out in case of identical ones
[09:16] <Cimi> pstolowski, since we want to be able to install scopes from any dev, I wanted to make sure we were safe from this side
[09:18] <pstolowski> Cimi, did you have a chance to explore/discuss the stuff we discussed 2 days ago about disabling clicks for new results for 100ms?
[09:19] <Cimi> pstolowski, dammit I forgot
[09:19] <Cimi> pstolowski, will do now
[09:56] <Cimi> tsdgeos, in two see more bugfix
[09:57] <tsdgeos> yep?
[09:57] <Cimi> why do we need all these qround ?
[09:57] <tsdgeos> because LVWPH code is crap
[09:57] <tsdgeos> basically
[09:57] <Cimi> maybe only contentY requires, no?
[09:57] <tsdgeos> all these
[09:57] <tsdgeos> you mean 2, no?
[09:57] <tsdgeos> there's no more
[09:57]  * tsdgeos checks
[09:59] <Cimi> tsdgeos, also shrkinking
[09:59] <Cimi> typo
[10:11] <tsdgeos> Cimi: ok, so the qRounds
[10:12] <tsdgeos> let me try to explain why they are there
[10:12] <Cimi> tsdgeos, I guess, rounding issues
[10:12] <Cimi> tsdgeos, but are all of them required?
[10:13] <tsdgeos> Cimi: yes both are
[10:13] <tsdgeos> so thign is
[10:13] <tsdgeos> LVWPH needs to show the header when you scroll up
[10:13] <tsdgeos> but not always
[10:13] <tsdgeos> for example if you are going up because of an overshoot, it doesn't
[10:13] <tsdgeos> so it uses a few heuristics to try to guess what's happening
[10:13] <tsdgeos> the qrounds are needed because
[10:14] <tsdgeos> we use perpixelscrolling in the view, so contentY will almost always be integer but not the contentHeight
[10:14] <tsdgeos> then if we are shrking the view
[10:15] <tsdgeos> it may happen that contentHegiht is smaller contentY+height because of those "rounding issues"
[10:15] <tsdgeos> and then the heuristic decides we have to show the header
[10:15] <tsdgeos> when we have not
[10:15] <tsdgeos> that's the best explanation i can give
[10:21] <Cimi> tsdgeos, trusting you
[10:21] <tsdgeos> Cimi: at least the huge qmluitests don't break :D
[10:22] <Wellark> mzanetti: I've been sick
[10:22] <Wellark> what's up?
[10:23] <mzanetti> Wellark: nothing really... just mterry tried to remove some of the Lockscreen api because it wasn't used...
[10:23] <mzanetti> so I just told him that you'll use it eventually
[10:25] <Wellark> mzanetti: ok.
[10:26] <Cimi> tsdgeos, approved both
[10:26] <tsdgeos> Cimi: \o/
[10:26] <Cimi> tsdgeos, I guess we want to rebase more things on memory on that
[10:26] <Cimi> tsdgeos, I realised it was against aacid branch, not unity-team
[10:27] <tsdgeos> ouch
[10:27] <tsdgeos> hope not much conflicts
[10:31] <om26er> mzanetti, Hi! in latest utopic image, right edge switcher is kind of broken. bug 1371047
[10:31] <mzanetti> uh oh
[10:31] <mzanetti> so that's in the image already
[10:32] <mzanetti> om26er: k, thanks. will take care
[10:32] <mzanetti> greyback: ^
[10:32] <mzanetti> greyback: any idea what could be causing this?
[10:33] <greyback> mzanetti: not yet
[10:33] <mzanetti> seems a mismatch of app + surfaces
[10:33] <mzanetti> given that its a entry in the spread, it must be that its an element in ApplicationManager
[10:33] <greyback> right
[10:34] <mzanetti> so in applicationCreatedSurface we probably fail to match the existing one and create a new one
[11:04] <mzanetti> elopio: ping
[11:51] <facundobatista> Holas
[11:52] <pstolowski> hey
[11:54] <pstolowski> tsdgeos, Cimi btw, here is the bug for tracking the disabling of results on new search we discussed https://bugs.launchpad.net/unity-scopes-shell/+bug/1238979
[11:55] <tsdgeos> pstolowski: get someone to assign it a critical
[11:55] <pstolowski> tsdgeos, Cimi also one of the last comments from Saviq describe his proposed solution
[11:55] <tsdgeos> we're not doing anything non critical these days
[11:55] <pstolowski> tsdgeos, btw, can you link your branch to it (but not MP'ed)?
[11:56] <tsdgeos> sure, lunch
[11:56] <pstolowski> tsdgeos, isn't rtm tag == critical?
[11:56] <tsdgeos> nope
[11:56] <pstolowski> ok
[12:02] <greyback> mzanetti: here's a fix: https://code.launchpad.net/~gerboland/qtmir/duplicate-open-apps/+merge/235109
[12:03] <greyback> mzanetti: feel free to choose someone to test :)
[12:06] <mzanetti> greyback is the hero of the day :)
[13:33] <mzanetti> MacSlow: notification autopilot tests broken. please fix
[13:34] <MacSlow> mzanetti, I've recently seen numerous (random) AP-tests failing... might be of that sort?
[13:34] <MacSlow> mzanetti, which branch are you talking about here?
[13:35] <mzanetti> I assume this one https://code.launchpad.net/~macslow/unity-notifications/fix-1335787/+merge/227334
[13:43] <dandrader> mzanetti, so lp:~gerboland/unity8/orientationLock got merged through "Focus first app if there are already some running when we're starting up Fixes: 1339883"
[13:44] <dandrader> mzanetti, was that intentional?
[13:44] <mzanetti> dandrader: no
[13:46] <dandrader> mzanetti, greyback is it going to break stuff if it lands without the qtmir, qtubuntu and papi counterparts?
[13:47] <mzanetti> dandrader: I don't *think* so, given I have tested the image before approving and it seemed to do fine
[13:47] <greyback> dandrader: I suspect not. We'll get extra warnings to the log
[13:47] <mzanetti> but still trying to figure what exactly this means
[13:52] <dandrader> greyback, just noticed that you have a dbusInterface in plugins/Unity/Session/orientationlock.h that's not used for anything :/
[13:55] <greyback> dandrader: that's reading a dbus property and watching it. But sure, it's not having any real effect atm
[13:59] <dandrader> greyback, really? I grepped for that variable and didn't see it mentioned anywhere besides its declaration
[14:00] <greyback> dandrader: OrientationLock.enabled is in qml/Shell.qml
[14:04] <dandrader> greyback, I still don't see it
[14:04] <greyback> dandrader: line 68?
[14:04] <dandrader> greyback,  I mean this "./plugins/Unity/Session/orientationlock.h:55:    QDBusInterface *dbusInterface;"
[14:05] <greyback> dandrader: oh oh I see what you mean. Yes oops
[14:05] <greyback> that's not used
[14:06]  * greyback surprised compiler didn't notice that
[14:52] <tsdgeos> pstolowski:  lp:~aacid/unity8/list_on_bottom_swipe
[14:52] <tsdgeos> i have there an initial implementation of the thing
[14:53] <tsdgeos> pstolowski: i understand that you'd do the sorting and making the second category actually "other" instead of "all" ?
[14:53] <tsdgeos> pstolowski: also if you can hack a branch with setFavorite enabled
[14:53] <tsdgeos> we can see what happens when you press stuff
[14:55] <pstolowski> tsdgeos, yes, i'll take care of that
[14:56] <pstolowski> tsdgeos, and thanks, that was fast!
[14:57] <tsdgeos> pstolowski: well i'm sure it needs work
[14:57] <tsdgeos> but it sets up something we can base on
[14:59] <greyback> dandrader|afk: https://code.launchpad.net/~gerboland/unity8/remove-unused-variable/+merge/235145
[15:07] <elopio> mzanetti: pong.
[15:13] <dandrader> greyback, done
[15:14] <greyback> dandrader: thanks! And well caught --  pity it wasn't during review ;)
[15:33] <mzanetti> elopio: hey, can I ask you for a favor?
[15:34] <mzanetti> elopio: when there's some time for it, could we fix unity8 AP tests so they aren't struggling with different languages?
[15:34] <mzanetti> right now a bunch of them fail if you don't have the phone set to en
[15:57] <elopio> mzanetti: we are trying to rely on objectNames, not texts. Unless it's like a name for a list item that we added during the test.
[15:57] <elopio> mzanetti: which ones have you found? To see if I have them in my radar
[16:01] <mzanetti> elopio: in the indicators there are a bunch
[16:02] <mzanetti> running unity8 tests with a non-english device should show it
[16:03] <elopio> mzanetti: they check the title, which is probably not necessary as I imagine you have QML tests that do that.
[16:04] <elopio> we should extend those autopilot tests to do something more useful than that.
[16:04] <elopio> I'll add an item on my TODO list. I should be able to work on it in ~2 weeks.
[16:04] <mzanetti> elopio: sounds reasonable... I didn't check details, just ran into this a couple of times now while landing stuff
[16:07] <dandrader_> mterry, is there a way to unlock the phone from command line?
[16:28] <greyback> mzanetti: second opinion please: I'm writing test for qtmir's DesktopFileReader. It will obviously need a desktop file to read. Is it clearer to have plain text desktop files in the repo to read, OR generate the desktop file to test in the C++ code to a temp file and read that?
[16:28] <greyback> dandrader: ^^
[16:29] <mzanetti> greyback: I for one prefer proper files
[16:29] <dandrader> greyback, can't you make the test read from a string in memory?
[16:29] <greyback> dandrader: not without plenty of work
[16:29] <dandrader> testing reading external files are potentially more brittle
[16:30] <mzanetti> having the real file there makes it easier to maintain imo
[16:30] <greyback> darn, now I'm back where I started :D
[16:30] <alecu> Cimi: hi! tsdgeos told me you may be working on this branch: https://code.launchpad.net/~unity-team/unity8/card-visual-tweaks/+merge/234332
[16:30] <greyback> as I'm torn between those options, for those very reasons
[16:30] <mzanetti> so I guess there's pro and cons :) do as you wish.. fwiw the launcher tests have files already
[16:31] <greyback> mzanetti: ah in that case, better be consistent
[16:31] <dandrader> greyback, when then having a pre-generated desktop file in the test dir would be the way to go...
[16:31] <mzanetti> although not much
[16:31] <dandrader> s/when/well
[16:31] <Cimi> alecu, I will, maybe tomorrow
[16:32] <greyback> tsdgeos: there?
[16:32] <alecu> Cimi: great. I've added some comments to it, because the spec seems to have been updated and there's code in the branch that should no longer be necessary
[16:33] <greyback> tsdgeos: actually, unping, I'm ok
[16:33] <Cimi> alecu, k
[16:33] <Cimi> alecu, ta
[16:43] <racarr> hmm qtmir doesn't quite sbuild...I wierded something up about the install causing it to try install without
[16:44] <racarr> qtmir(cmake)
[16:44] <racarr> trying to install without...the right priveleges?
[17:00] <tsdgeos> greyback: i am now
[17:01] <greyback> tsdgeos: it's ok, sorry for poking you
[17:01] <tsdgeos> no worries
[17:01]  * tsdgeos leaves for good
[17:24] <mterry> dandrader, yes you can unlock from command line
[17:24] <mterry> There is a dbus command you could do
[17:24] <mterry> hold on
[17:24] <mterry> dandrader, gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter
[17:24] <dandrader> mterry, ok, thanks
[17:59] <racarr> Ah! I see. make install is faling because
[17:59] <racarr> debian/rules for qtmir uses this weird double build dir system for
[17:59] <racarr> building android v.normal
[18:00] <racarr> and changes the install root via an INSTALL_ROOT variable that qmake uses but cmake doesnt
[18:44] <mterry> macsl
[18:44] <mterry> whoops
[21:19] <mzanetti> alecu: ping
[21:19] <alecu> mzanetti: pong
[21:19] <mzanetti> alecu: hey, the MP you asked for is in silo 007
[21:19] <alecu> wow, I feel like a secret agent
[21:20] <mzanetti> :D
[21:20] <alecu> mzanetti: thanks, I'll give it a round of testing now
[21:20] <mzanetti> alecu: that silo has currently one issue. apps don't start from the launcher. I have fixed that and am kicking a rebuild
[21:20] <mzanetti> alecu: but other than that it passed my manual testing, so should be good for you try the purchase thing
[21:20] <alecu> great
[22:37] <racarr> I wonder if its ok not to build qtmir-desktop for armhf
[22:37] <racarr> ugh
[22:37] <racarr> I guess it should build
[22:55] <racarr> Wheeeeeeeeee something built
[22:56] <racarr> cross built that is