[08:08] <mlankhorst> is bschaefer on irc?
[08:13] <mzanetti> MacSlow: good morning, and welcome back
[08:13] <mzanetti> greyback: good morning to you too. (I'd have another 3 branches to be reviewed :/ )
[08:13] <MacSlow> mzanetti, hey there... thanks... just getting back into everything...
[08:14] <MacSlow> bazillion emails :)
[08:14] <mzanetti> MacSlow: Need a hangout with you and dednick asap
[08:14] <mzanetti> MacSlow: there's a high priority thing where we need your help
[08:14] <MacSlow> sure... this afternoon?!
[08:15] <greyback> mzanetti: let me have a look
[08:15] <greyback> MacSlow: welcome back!
[08:15] <MacSlow> hey greyback
[08:15] <mlankhorst> I'm working on porting saucy xserver back to precise, but I need some help to get unity working (pointer barrier changes)
[08:16] <greyback> mzanetti: lp:~mzanetti/unity8/launcher-appmanager been sitting in the "ready to land" queue for a long time now. Jenkins stuck again?
[08:16] <MacSlow> dednick, mzanetti: how about a hangout this afternoon, right after the stand-up?
[08:16] <mzanetti> greyback: this is an easy one: It was discovered by the OEM customization team and already tested by them: https://code.launchpad.net/~mzanetti/unity8/fix-launcher-search-path/+merge/183943
[08:16] <mzanetti> MacSlow: no... rather now or in a couple of minutes :P
[08:16] <greyback> mzanetti: yep, just approving :)
[08:17] <MacSlow> mzanetti, dednick: ok :)
[08:17] <mzanetti> greyback: here's another relatively easy one: https://code.launchpad.net/~mzanetti/unity-api/launcher-add-focused
[08:17] <mzanetti> greyback: it prepares the api for the next one
[08:17] <mlankhorst> I've fixed the ubuntu libs in precise to work against both xserver pointer barrier abi's. unity can detect at runtime if xinput 2.3 is supported, if it is it could use the new pointer barrier api, if it's not it can fallback to the old one. This means that a single unity binary would be enough for all xservers. :P
[08:18] <mzanetti> greyback: this is the third one: https://code.launchpad.net/~mzanetti/unity8/launcher-focused-highlight/+merge/183979
[08:18] <dednick> mzanetti, MacSlow: yeah, nowish is fine for me.
[08:18] <mzanetti> +1
[08:18] <mzanetti> greyback: yeah... jenkins had lots of problems... I'll keep track of it and get stuff merged
[08:19] <mlankhorst> meh screw it, I'll just try to make it work myself
[08:19] <greyback> mzanetti: ack. I'm on those reviews
[08:19] <mzanetti> greyback: thanks a bunch
[08:19] <greyback> np
[08:20] <MacSlow> dednick, mzanetti: just calling you on the hangout
[08:21] <mzanetti> MacSlow: ?
[08:21] <MacSlow> dednick, mzanetti: didn't work
[08:21] <mzanetti> MacSlow: I never understood how that is supposed to work
[08:21] <mzanetti> well. for someone that _lives_ inside the browser it probably does
[08:21] <dednick> MacSlow: i think it only works with american numbers or something
[08:22] <MacSlow> dednick, mzanetti: I just pick you from the list of known contacts on G+
[08:22] <MacSlow> dednick, mzanetti: there are no "numbers"
[08:22] <dednick> MacSlow: most likely need to be logged in
[08:22] <mzanetti> MacSlow: yeah... causes a notifications in one of my 300 browser tabs...
[08:22] <MacSlow> dednick, mzanetti: not as far as I know
[08:22] <mzanetti> don't count on me finding that in time
[08:22] <MacSlow> dednick, mzanetti: :)
[08:24]  * mzanetti isn't able to start a new hangout any more since the last google+ design changes
[08:35] <greyback> mzanetti: https://code.launchpad.net/~mzanetti/unity8/launcher-focused-highlight/+merge/183979 needs commit message
[09:12] <greyback> mzanetti: unity8/launcher-focused-highlight approved
[09:12] <mzanetti> greyback: nice :)
[09:12] <Mirv> greyback (and others): FTBFS https://bugs.launchpad.net/unity8/+bug/1221102
[09:14] <greyback> Mirv: yeah, Jenkins issues causing landing delays. Hope they'll land soon, so that will go away
[09:17] <Mirv> greyback: ok. asa_c seems to wish no other changes than FTBFS fixes landing for today's eventual unity8/mir migration
[09:19] <greyback> Mirv: well bit late to tell me that now. There's a few launcher related MRs landing now. Then we can hold off
[09:19] <Mirv> greyback: ok. of course all perfect commits are welcome :)
[09:35] <dednick> mzanetti: ofono branch has trunk conflicts btw
[09:35] <mzanetti> dednick: yeah... I merged them yesterday already... just haven't pushed yet
[09:35] <mzanetti> will do so soon
[09:59] <nic-doffay> pstolowski, ping
[10:10] <mhr3> dednick, are there any real non-qml unit tests somewhere in unity8 tree?
[10:10] <dednick> mhr3: yeah, in the tests/plugin folder.
[10:11] <mhr3> aaah, missed that
[10:11] <mhr3> thx
[10:44] <sil2100> greyback: hi!
[10:44] <greyback> sil2100: hey
[10:44] <sil2100> greyback: so, this change will fix the FTBFS problem in unity8?
[10:44] <sil2100> https://code.launchpad.net/~mzanetti/unity8/launcher-appmanager/+merge/183837 ?
[10:45] <greyback> sil2100: waiting for unity-api release to be made, and then when that lands, everything should be ok
[10:45] <mzanetti> FTBFS?
[10:46] <greyback> mzanetti: https://bugs.launchpad.net/unity8/+bug/1221102
[10:47] <sil2100> Re-running the unity8 stack then
[10:51] <mzanetti> greyback, sil2100: it's merged already, but by now we landed the next api change in unity-api which requires this to land: https://code.launchpad.net/~mzanetti/unity8/launcher-focused-highlight/+merge/183979
[10:52] <mzanetti> busy times around here :D
[10:52] <greyback> oops, sorry for pointing to wrong branch
[10:52] <sil2100> uuuh
[10:53] <sil2100> Ok, so it still won't work without it?
[10:56] <nic-doffay> mzanetti, regarding the tests. Do we absolutely have to test the option selectors within the filter drop down? The reason being is that they rely on the scopes, and populating them with other dummy model data would mean exposing quite a lot of variables in the pageHeader which I feel should remain private...
[11:02] <mzanetti> nic-doffay: well, you could findChild() on the listview and set a different model there
[11:03] <mzanetti> nic-doffay: but no, I don't want lots of tests if the optionselectors work correctly in there
[11:03] <mzanetti> nic-doffay: basically just checking if they are there and can be clicked
[11:03] <mzanetti> nic-doffay: but just brainstorming. maybe it doesn't make much sense
[11:04] <mzanetti> nic-doffay: just test whatever you think makes sense.
[11:06] <nic-doffay> mzanetti, it's a little more complicated since it uses a custom delegate.
[11:06] <nic-doffay> That's bound by the PageHeader.
[11:10] <sil2100> greyback, mzanetti: we might need to forcefully merge in https://code.launchpad.net/~mzanetti/unity8/launcher-focused-highlight/+merge/183979 , since the auto-merger doesn't pull in the daily-build PPA
[11:10] <sil2100> greyback, mzanetti: and as unity8, unity-api and unity-mir are all part of the same stack, they're blocking eachother
[11:11] <mzanetti> sil2100: thats news to me... we did those kind of changes quite often already and it seems to work fine
[11:11] <sil2100> mzanetti: well, greyback said something that it's waiting the release of some change in unity-api, right?
[11:12] <sil2100> mzanetti: since I see CI failing constantly for this branch
[11:12] <mzanetti> sil2100: no... its running right now and seems to pass
[11:13] <mzanetti> sil2100: everything fine I think
[11:13] <sil2100> Ok, so I might have misunderstood greyback there
[11:14] <greyback> sil2100: once Jenkins catches up, everything /should/ be ok. Just bad timing that we change stuff in unity-api, causing unity8 to break, as things didn't land in the order they should have
[11:14] <sil2100> Ah, right
[11:15] <greyback> sil2100: sorry for confusion
[11:15] <sil2100> No problem, I just misunderstood the situation ;)
[11:15] <nic-doffay> mzanetti, I've commented and pushed to the MP if you don't mind taking a look when you're able to and giving your thoughts on there: https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/183503
[11:48] <sil2100> greyback, mzanetti: failed again: https://code.launchpad.net/~mzanetti/unity8/launcher-focused-highlight/+merge/183979
[11:48] <mzanetti> greyback: yeah... saw that
[11:48] <mzanetti> already retriggered it
[11:49] <mzanetti> greyback: Java.Lang.InterruptException
[11:49] <mzanetti> dafuq
[11:49] <greyback> Jenkins still not happy :(
[12:04] <mlankhorst> You lose, you lose!
[12:28] <kgunn> nic-doffay: ping
[12:28] <kgunn> MacSlow: welcome back!
[12:32] <mzanetti> greyback: hmm... not sure why our qmltests builder is still not happy with it :/
[12:34] <greyback> mzanetti: "java.lang.InterruptedException"
[12:34] <mzanetti> greyback: no. this one failed becuase of the FocusedRole
[12:39] <dandrader> mzanetti, continous integration is still pretty broken, right?
[12:40] <mzanetti> dandrader: yeah. it seems something bad has happened during the last power outtake
[12:47] <mzanetti> greyback: sil2100: seems our jenkins configs are broken since the last outtake and cannot be edited any more.
[12:47] <greyback> oh no
[12:47] <sil2100> uuh
[12:48] <sil2100> mzanetti: maybe fginther can help?
[12:48] <mzanetti> yeah, but he's not around yet
[12:49] <mzanetti> but I've found the issue why the qmltestrunner job doesn't like the merge.
[12:49] <nic-doffay> kgunn, what's up?
[12:49] <mzanetti> so once fginther is back I think I can resolve it and land stuff
[12:50] <kgunn> nic-doffay: hey, wrt info-g
[12:50] <kgunn> is there already an api that 3rd parties can implement against to deliver
[12:50] <kgunn> data/info to be displayed ?
[12:51] <kgunn> or is it all still sort of "closed" ...only available to resident apps (that ship as part of the os)
[12:52] <dandrader> mzanetti, would you have time to review this one? https://code.launchpad.net/~dandrader/unity8/fakeRunningApps/+merge/183540
[12:52] <nic-doffay> kgunn, ask away
[12:53] <MacSlow> kgunn, thx
[12:53] <mzanetti> dandrader: yep. will do
[12:53] <dandrader> mzanetti, thanks!
[12:58] <kgunn> nic-doffay: did you get my posts ?....something seems strange/delayed about irc
[13:01] <kgunn> nic-doffay: trying again :)....so, is there an api available today for 3rd parties to feed their data to be displayed as part of the infographic ?
[13:02] <nic-doffay> kgunn, not that I'm aware of.
[13:02] <kgunn> nic-doffay: ...might be a question for pete-woods-lunch
[13:02] <nic-doffay> kgunn, was about to suggest that :)
[13:03] <kgunn> thostr_: ^ actually...do you know ?
[13:09] <thostr_> kgunn: yes there is
[13:09] <kgunn> thostr_: thanks...is there a wiki or a pointer to it ? ....or, here's a header good luck :) ?
[13:09] <thostr_> kgunn: http://developer.ubuntu.com/api/devel/ubuntu-13.10/cplusplus/usermetrics/
[13:10] <kgunn> thostr_: you're so good!...thanks
[13:10] <thostr_> kgunn: but a word of warning: the infographic stuff might change for 14.04! We'll add a note to the doc... and then I'll get back to the guy on the mailing list
[13:39] <mterry> pete-woods-lunch, poke when you get back.  We talked about adding a bit of API to libusermetricsoutput to say "disable user-specific info", but I was working on the unity8 side yesterday when I realized, why don't we just set the user to ""?  And theoretically, if we had system-data, we could still show that for the null user
[13:42] <pete-woods-lunch> mterry: that could work, yes, currently the system data is actually stored under the "" user
[13:42] <pete-woods> mterry: it's merged into each of the user's data at the moment
[13:42] <mzanetti> greyback: sil2100: put some glue on the jenkins config and hopefully now it should go through. I just triggered the job
[13:43] <pete-woods> mterry: the output could very easily expose it under the "" user
[13:43] <pete-woods> *output API
[13:49] <sil2100> mzanetti: phew
[13:50] <mzanetti> sil2100: well. its still broken... but we can still modify some parts of it through the jenkins web API
[13:50] <mzanetti> sil2100: the website config dialog still bails out when opening
[13:55] <mzanetti> greyback, sil2100: \o/ it passed the critical point... not we just need a run without any network outtakes or device failures :D
[13:55] <greyback> :)
[14:00] <sil2100> ;p
[14:17] <mhr3> mzanetti, saviq's switch tells me you want to review https://code.launchpad.net/~mhr3/unity8/hide-gicons/+merge/184082 ;)
[14:18] <mzanetti> mhr3: heh. ok. I'll do
[14:18] <kgunn> mterry: so...just curious, if you turned on lockscreen today...would the lock screen still need to be user enabled through the settings app ? or would it just awkwardly show up/with no way to turn it off ?
[14:18] <mterry> kgunn, the latter
[14:18] <mterry> except you can turn it off the same way you turned it on (via an ini file)
[14:19] <kgunn> mterry: hmm, i suppose this is true even when we get mir-on-mir ?
[14:19] <mterry> kgunn, the settings app should be able to control the lockscreen presence once we are split
[14:20] <kgunn> seb128: ^ is that something you're already accounting for ?
[14:21] <mterry> He and I talked about it before
[14:23] <kgunn> mterry: seb128 ... was just thinking, cheap hack could be to use the ini as a global store between settings & greeter (bit more user friendly) in advance of mir-on-mir
[14:23] <mterry> kgunn, you mean just temporarily?
[14:24] <kgunn> mterry: :) yes of course
[14:24] <mterry> kgunn, I wouldn't be opposed, but of course there's no security in it, but I assume testers don't expect any...?
[14:25] <kgunn> mterry: right...its more about appearance/ux....while the foundation moves underneath
[14:25] <kgunn> mterry: that way it wouldn't just awkwardly show up & have the enable/disable capability
[14:26] <kgunn> it'll depend on where that is in seb128 's queue...
[14:27] <mzanetti> I'm happy to announce that CI works again :D
[14:31] <mzanetti> mterry: haven't you recently done something similar? https://code.launchpad.net/~mhr3/unity8/hide-gicons/+merge/184082
[14:31] <mlankhorst> where does unity store its settings in precise?
[14:32] <mhr3> mzanetti, what do you mean?
[14:32] <mhr3> i had that branch for a while
[14:32] <mhr3> just didn't have tests
[14:32] <mhr3> and was waiting for the sdk
[14:32] <mzanetti> mhr3: I just thought we would already have switched to image://theme
[14:33] <mzanetti> mlankhorst: dconf-editor
[14:33] <mhr3> mzanetti, we will with this :)
[14:38] <mlankhorst> mzanetti: in precise?
[14:39] <mzanetti> mlankhorst: I believe so... yes. altough I'm not sure
[14:40] <mlankhorst> hm it does contain some stuff, still haven't found unity shell config though
[14:51] <mlankhorst> bschaefer: oh btw I've done something really ugly, I backported the pointer barriers to precise for x-staging ppa.. no idea why it's failing though :P
[14:51] <mlankhorst> it seems to work fine now, but no pointer barrier is created for the second monitor
[14:52] <bschaefer> hmm i have to remember how that code worked :)
[14:52] <mlankhorst> I gave up on trying to understand it and just backported the commit blindly, but kept the old pointer barriers
[14:52] <bschaefer> mlankhorst, so its just in the x-staging ppa?
[14:53] <mlankhorst> soon
[14:53]  * bschaefer can have a look at it later today
[14:53] <mlankhorst> I'm preparing the saucy backports, so I wanted a version of unity with both types of pointer barriers
[14:53] <bschaefer> mlankhorst, thanks for looking at the backport though :), I do remember running into a problem where I just didn't receive events
[14:54] <mlankhorst> well afaict all the setup is fine, it's just not being done :P
[14:54] <bschaefer> cool, does this mean we are back porting the new x11 as well?
[14:54] <mlankhorst> I've put a breakpoint on constructbarrier which wasn't triggered as often as it should..
[14:54] <bschaefer> very strange...
[14:55] <mlankhorst> bschaefer: yeah but it's working fine otherwise, the pointer barrier at 0x0 usually works, but multimonitor does not
[14:55] <bschaefer> mlankhorst, cool, well Ill grab the ppa later on my 12.04 partition and give a look into it!
[14:55]  * bschaefer has a meeting to go to
[14:56] <mlankhorst> bschaefer: yeah it's a bit ugly, it looks like you moved events from 1 place to the other, I just kept both places, the old event handling for xfixes barriers, new place for xi2 barriers :P
[14:57] <mlankhorst> though maybe I should drop the use of the pointerbarriervelocity call and unify it
[14:57] <mlankhorst> no idea if that path is even tested though
[14:57] <bschaefer> mlankhorst, well there was some other changes to the xbarriers IIRC recently
[14:58] <mlankhorst> a bit, I didn't port the horizontal/vertical stuff, and there have been a ton of api changes I didn't copy either
[14:58] <bschaefer> cool, yeah the chunk of the work is the handling of the event it self from nux...which is done in a strange way
[14:59] <bschaefer> the creation should be done in the launcher? (IIRC), ill have to double check that
[15:00] <mlankhorst> just diff unity 5.20.0-0ubuntu3~ppa1 against 5.20.0-0ubuntu2 to find the diff, it's newer than 0ubuntu3, I forgot to fixup version :P
[15:00] <bschaefer> no worries :), and cool!
[15:04] <greyback> mlankhorst: no idea if it's useful for you, but we implemented PointerBarrier in unity-2d for precise also. The alternative implementation might give you some clues?
[15:08] <mlankhorst> greyback: yeah I'm aware, that needs backporting too :P
[15:08] <seb128> kgunn, hey, sorry I was out for a bit ... did mterry and you sort it out?
[15:08] <seb128> kgunn, I'm fine with whatever config interface/format you guys suggest, as long as system settings can access it easily
[15:08] <mlankhorst> greyback: it looks more like on resolution change pointer barriers do not get set up again, my break against ConstructBarrier doesn't always trigger
[15:09] <kgunn> seb128: this would be short term, just to enable some of the ui/ux before v1.0
[15:09] <mlankhorst> greyback: but it looks easier to fix pointerbarriers in unity2d :P
[15:09] <seb128> kgunn, what interface do you suggest?
[15:09] <kgunn> seb128: but not overly involved (e.g. cheap)
[15:09] <mlankhorst> bbl
[15:09] <kgunn> seb128: mterry was thinking just a 1 line in an ini file
[15:09] <kgunn> that setting would read/write
[15:09] <greyback> mlankhorst: hopefully is. Let me know if you need a hand, it's my old project
[15:09] <kgunn> and greeter would read
[15:10] <mterry> seb128, well, two lines.  One for type (none, pin, password) and one for password/pin value
[15:10] <mterry> seb128, first "type" value is supported today
[15:10] <seb128> kgunn, mterry: is the config file owned by the phablet user or a system one? if it's a system it would require us to have a way to gain privileges to edit it (e.g polkit)
[15:10] <mterry> seb128, second password/pin value I've got a branch for
[15:10] <mterry> seb128, its ~/.unity8-greeter-demo I think
[15:10] <seb128> mterry, +1 then
[15:10] <mterry> seb128, just a dummy file we've been using
[15:11] <mterry> seb128, support for it is already in images.  You just have to use hardcoded passwords right now (being changed as we speak)
[15:11] <mterry> seb128, so you could start supporting it
[15:12] <mzanetti> dandrader: what's up with this one? https://code.launchpad.net/~dandrader/unity8/runningApps_lp1193419/+merge/177630
[15:13] <mterry> seb128, format will look like:
[15:13] <mterry> [General]
[15:13] <mterry> passwordValue=4890
[15:13] <mterry> password=pin
[15:14] <mterry> in ~/.unity8-greeter-demo
[15:14] <dandrader> mzanetti, I've to update it on top of the one I asked you to review
[15:14] <mzanetti> dandrader: the other is merge already
[15:14] <mzanetti> merged
[15:15] <dandrader> mzanetti, and I was having a very tough time trying to make jenkins successfully run that test.
[15:15] <dandrader> mzanetti, fingers crossed it won'
[15:15] <mzanetti> heh :)
[15:15] <dandrader> t happen after I rebase with latest trunk
[15:16] <mzanetti> dandrader: when we're not having such issues depending on unity-api, our ci is quite stable nowadays
[15:16] <mzanetti> dandrader: om26er and I have been able to nail down some issues last week
[15:16] <dandrader> nice
[15:17] <mzanetti> mhr3: ah... this is the one I meant before: https://code.launchpad.net/~mterry/unity8/unity-theme-provider/+merge/183745
[15:18]  * mterry looks up
[15:18] <mzanetti> mterry: I think it conflicts with yours
[15:18] <mzanetti> err... mhr3...
[15:18] <mzanetti> well.. both of you :D
[15:18] <mterry> Oh shoot, did I duplicate effort?  Sorry
[15:18] <seb128> mterry, great
[15:18] <mzanetti> fight over it
[15:19] <seb128> mterry, do you have the format documented somewhere?
[15:19] <mzanetti> seb128: this is temporary
[15:19] <mhr3> looks like we should have both
[15:19] <mterry> seb128, you just saw it  :)
[15:19] <mhr3> ...ish
[15:19] <mzanetti> mhr3: yeah... but mterry would need to drop his changes in IconUtil.js
[15:19] <seb128> mterry, mzanetti: can you drop that a comment in https://bugs.launchpad.net/ubuntu-system-settings/+bug/1218010 so Laney knows about it (he's working on that code)
[15:19] <mhr3> mzanetti, yep
[15:20] <mzanetti> mhr3: will the rest of mterry's changes still work with your new iconUtil stuff?
[15:20] <mhr3> mzanetti, well my branch is dropping that
[15:21] <mhr3> but the s/gicon/theme/ is still needed
[15:21] <mterry> mzanetti, mhr3: well, most of my string replaces are still good
[15:21] <mterry> yeh
[15:21] <mhr3> or well.. wanted
[15:21] <mterry> but I guess I don't need the iconUtil.js stuff
[15:21] <mhr3> right
[15:21] <mterry> I'd say land mhr3's first, then I can rebase
[15:21] <mzanetti> ack
[15:23] <mzanetti> pstolowski: can you review this one? https://code.launchpad.net/~aacid/unity8/lvwph_update_section_header/+merge/183457
[15:30] <mterry> mzanetti, what is a common lightweight way to modify the behavior of a mock plugin for testing purposes?  environment variables?
[15:31] <mzanetti> mterry: well, in a mock you can just add additional public methods
[15:31] <mterry> mzanetti, oh...  fair
[15:31] <mzanetti> mterry: so basically your mock should implement the api defined in unity-api, but then it can extend it for testing purposes
[15:32] <mzanetti> mterry: while the real plugin needs to stick exactly to unity-api
[15:32] <mzanetti> that's the idea at least
[15:32] <katie> mzanetti, mterry you guys want a  greeter catch up?
[15:32] <katie> nothing to report from me
[15:32] <mterry> katie, i had a couple questions....
[15:32] <mterry> let me dig them up
[15:32] <mzanetti> same here
[15:32] <mzanetti> well, 1 only really
[15:32] <mzanetti> but still
[15:32] <katie> lets go hangout then :)
[15:43] <pstolowski> mzanetti: hi, I can, but the problem is it doesn't fix the original problem it was supposed to fix
[15:55] <mzanetti> pstolowski: oh... well... feel free to note that down in the MR and put it to needs fixing
[15:58] <pstolowski> mzanetti: k
[15:59] <dandrader> mzanetti, do you get this when trying to build a package out of the latest unity-api/trunk? http://paste.ubuntu.com/6067008/
[16:02] <mzanetti> dandrader: nope. all passing here
[16:02] <mhr3> mzanetti, hmm, i started to look into how often is the data called, are there's something fishy :/
[16:03] <mhr3> when just viewing stuff it's fine, but when the model is cleared, it's getting called for every row
[16:04] <mzanetti> mhr3: yeah... that
[16:04] <mzanetti> 's how it works
[16:04] <mhr3> guess that's coming from qtdee + limitproxy interaction
[16:05] <mzanetti> mhr3: ofc it is called for every row... that's why I say. you shouldn't do expensive string operations in there
[16:05] <mzanetti> mhr3: actually its called rowCount * columnCount * roleCount
[16:06] <mhr3> mzanetti, but it should be called exactly 0 times when the model is being cleared
[16:06] <mzanetti> mhr3: depends how you clear the model
[16:07] <mzanetti> mhr3: if you do a beginRemoveRow(0, count-1); endRemoveRows() it won't be called
[16:07] <mhr3> right, unfortunately that's not the case
[16:07] <mzanetti> mhr3: if you remove each line one by one and perhaps emit some dataChanged in between, yes... its getting bad
[16:08] <mhr3> yea, dee removes one by one, and limitproxy emits datachanged,  together we get a disaster :/
[16:08] <mzanetti> outch
[16:09] <mhr3> but a few extra string comparisons is the smaller problem here
[16:09] <mzanetti> indeed
[16:10] <mzanetti> still... both should not happen
[16:10] <mhr3> if it was easy to fix it they wouldn't be :P
[16:11] <mzanetti> right...
[16:12] <mhr3> i think it'll need to do some changes to dee
[16:13] <mhr3> pstolowski, got too many things to do? ^ :D
[16:13] <mhr3> i mean... too few?
[16:14] <pstolowski> mhr3: thank you, i'm not complaining ;)
[16:14] <mzanetti> you will soon :D
[16:15] <dandrader> mzanetti, ok, it works if I don't use ccache
[16:15] <mzanetti> dandrader: interesting
[16:15] <dandrader> (the unity-api package building issue)
[16:43] <mzanetti> mterry: trying to test this: https://code.launchpad.net/~mterry/unity8/start-stop-demo/+merge/183947 turning on doesn't seem to work
[16:43] <mterry> :-/
[16:43] <mterry> will look
[16:43] <mterry> in a bit though, eating
[16:47] <mzanetti> mterry: stupid me... I messed up the merge.. needs manual merging with trunk tho
[16:49] <mterry> guh, ok
[17:14] <cwayne_> hey guys, is unity8 in utouch hardcoded to only allow for 4 master scopes?
[17:14] <cwayne_> i changed the dconf key to add more and it only shows the first 4 now
[17:14] <mzanetti> mhr3: ^
[17:15] <mhr3> cwayne_, no
[17:15] <mhr3> works fine with all the desktop ones when you run it on desktop
[17:16] <mhr3> and there's 7 of those
[17:16] <mzanetti> cwayne_: did you install additional ones on the phone?
[17:16] <cwayne_> mzanetti, no, i just added some to the dconf key
[17:16] <cwayne_> i already seem to have quite a few installed, though i didn't explictly install them
[17:16] <mzanetti> cwayne_: I think just installing more of them should be enough to make them appear
[17:16] <mhr3> then what you added wasn't valid i guess
[17:16] <cwayne_> ah, i made a stupid typo!
[17:16] <cwayne_> i did mockvideomaster instead of mockvideosmaster
[17:17] <cwayne_> sorry to bother you guys!
[17:33] <mzanetti> mterry: if you don't mind, also for consistency with other plugins I think we should keep c++ classes and qml item names the same.
[17:34] <mterry> mzanetti, OK, can fix