[07:07] <Saviq> morning
[07:08] <Saviq> mzanetti, fyi, bug #1491566 is getting more and more heat
[07:40] <Saviq> mzanetti, also fyi, mir and u-s-c are there in silo 14 now, too
[07:41] <Saviq> there's just one thing I don't necessarily understand there
[07:41] <Saviq> mir in wily is 0.15.1, in overlay it's 0.14.1
[07:42] <Saviq> so not really a no-change rebuild, is it...
[08:07] <tsdgeos> Saviq: overlay (or vivid) has some 0.13 bits that end up in the image, i wonder if that's because some rebuilds are needed or because we actually want to ship those 0.13 bits to support "old" click apps
[08:08] <Saviq> tsdgeos, you mean the image has some 0.13 mir bits?
[08:08] <tsdgeos> Saviq: yep
[08:08] <tsdgeos> ii  libmirclient8:armhf                                  0.13.3+15.04.20150617-0ubuntu1                        armhf        Display server for Ubuntu - client library
[08:08] <tsdgeos> ii  libmircommon4:armhf                                  0.13.3+15.04.20150617-0ubuntu1                        armhf        Display server for Ubuntu - shared library
[08:09] <Saviq> https://launchpad.net/ubuntu/+source/mir vivid has 0.12
[08:09] <Saviq> hmm interesting what pulls that in
[08:09]  * Saviq checks
[08:09] <tsdgeos> gdk3
[08:09] <tsdgeos> and libubuntu-platform-hardware-api2:armhf
[08:09] <tsdgeos> which is also not used by anyone and could be dropped
[08:10] <Saviq> looks like mir 0.14 was release without rebuilding
[08:10] <tsdgeos> unless we want it there for retro compatibility
[08:10] <anpok> but platform-api was rebuilt with 0.15
[08:10] <anpok> sorry
[08:10] <anpok> 0.14
[08:10] <anpok> but I guess libubuntu-platform-hardware-api2 is listed somewhere - i.e. app support?
[08:11] <anpok> which version of gdk3?
[08:11] <anpok> vivid+overlay should have 3.14 and that was part of the 0.14 landing iirc
[08:13] <Saviq> anpok, http://pastebin.ubuntu.com/12271399/
[08:13] <mzanetti> hey
[08:14] <Saviq> anpok, yeah, libgtk-3-0 deps on libmirclient8 (>= 0.12.1+15.04.20150324)
[08:15] <Saviq> but that looks fine, >=
[08:15] <Saviq> ah wait, 8, which means previous ABI
[08:16] <Saviq> but apparently there's more like that
[08:17] <Saviq> somehow mir-test-tools, mir-utils 0.14 also depend on libmirclient8 :?
[08:19] <Saviq> it looks like a bunch of things were not rebuilt for 0.14
[08:23] <anpok> hmm the gtk 3.14 that was built with mir-0.14 is not in the stable phone ppa
[08:26] <Saviq> ah wait, qtubuntu-android is fine, the version in the overlay ppa deps on libmirclient9
[08:27] <Saviq> http://i.imgur.com/999gfHq.png
[08:28] <Saviq> but regardless of gtk, ubuntu-touch pulls it in, too
[08:29] <anpok> guess there might be apps using the api version 2 of platform api
[08:30] <Saviq> anpok, yeah, but shouldn't platform 2 be rebuilt against new mir? or has there been incompatibilities?
[08:30] <anpok> i wonder where the gtk3 package was lost.. we did spend some time porting and testing that on vivid
[08:31] <anpok> hm I dont know exactly.. it might leak mir parts
[08:32] <anpok> -might leak +leaks
[08:32] <Saviq> uhm
[08:37] <cimi> tsdgeos, how do you want to split the work for the filters?
[08:39] <cimi> I suppose I can do those components like the previews, shouldn't be too hard
[08:40] <tsdgeos> cimi: can you start trying to do the option selector component while i finish the mock backend for it and when we're both done we can hook it up in a test?
[08:43] <cimi> ok
[08:47] <cimi> tsdgeos, you have a junk branch I can rebase?
[08:47] <cimi> tsdgeos, or we do overlay for now?
[08:49] <tsdgeos> cimi: yes
[08:49] <tsdgeos> cimi: https://code.launchpad.net/~aacid/unity8/filters
[08:56] <Saviq> @unity please don't (re)target MPs to lp:unity8/overlay, we're getting rid of that asap
[08:56] <tsdgeos> cimi: just realized for that branch you'll need a unity-api that doesn't exist outside my computer, will junk push it somewhere
[08:57] <cimi> Saviq, what's the plan? clearing up the overlay review list then merge back?
[08:58] <Saviq> cimi, there's a silo merging trunk (just .po changes) into overlay, that's gonna land on overlay along with a few branches (silo 14)
[08:58] <Saviq> cimi, then we push that to trunk and delete overlay, so anything remaining there will have to be resubmitted against lp:unity8 again
[08:58] <Saviq> cimi, unfortunately there's no easy transition
[08:59] <cimi> Saviq, finishing approving all overlay branches then merge back no?
[08:59] <tsdgeos> cimi: you can use lp:~aacid/unity-api/ignore_filters_15.04
[08:59] <Saviq> cimi, and what about all the new branches in between/
[08:59] <Saviq> and how long do we keep overlay going?
[08:59] <cimi> Saviq, we try to approve quickly :P :D
[09:00] <Saviq> cimi, it's easy enough to just resubmit the remaining ones against trunk
[09:00] <Saviq> you won't even have to rebase, as the history will be the same
[10:27] <Saviq> mzanetti, ok, silo 14 looks sane now
[10:27] <Saviq> mzanetti, but since it's an upgrade of mir into vivid, we'll need to test Mir, too, or employ someone from there to do it
[10:28] <Saviq> hmm but wait, we need qtubuntu and platform-api in there now, too, then
[10:28] <mzanetti> :)
[10:28] <mzanetti> see you on monday then, I guess
[10:29] <mzanetti> just make sure you don't pull in the kernel
[10:30] <Saviq> d'oh
[10:30] <greyback__> Saviq: only if mirclient api changes...O hope
[10:30]  * Saviq checks
[10:31] <Saviq> hmm libmirclient9, so hopefully that's fine
[10:32] <Saviq> mirserver got a bump
[10:33] <greyback__> should only impact qtmir
[10:35] <Saviq> and mirplatform
[10:36] <Saviq> so need to rebuilt qtmir for sure
[10:38]  * Saviq kicks
[10:43] <tsdgeos> cimi: how did the listview for comments end?
[10:43] <cimi> tsdgeos, it sounds to me we will need a redesign anyway
[10:43] <tsdgeos> why?
[10:44] <cimi> tsdgeos, something like collapsed by default
[10:44] <cimi> tsdgeos, are we really going to show 1000+ comments in a single listview?
[10:44] <tsdgeos> why not?
[10:44] <tsdgeos> what does it matter if they are collapesed or not?
[10:45] <cimi> tsdgeos, if our issue is loading, we don't have a problem is they are collapsed by default
[10:46] <tsdgeos> how do you collapse 1000 comments?
[10:46] <tsdgeos> i don't even understand what you mean by collapsed comment
[10:47] <tsdgeos> do you mean not showing them at all
[10:47] <tsdgeos> ?
[10:47] <tsdgeos> and have a "show comments"?
[10:47] <Saviq> greyback__, mzanetti, any ideas to investigate bug #1491566 ? I only have mako and krillin, and have not seen that issue
[10:48] <mzanetti> Saviq, spend a while trying to repro yday... haven't managed
[10:48] <Saviq> *spent
[10:48] <mzanetti> Oh, how I missed that
[10:48]  * Saviq no has time machine to spend time yesterday
[10:48] <Saviq> :D
[10:48] <greyback> so nice to have captain pedantic back
[10:49] <cimi> tsdgeos, yeah
[10:49] <Saviq> mzanetti, that just means you didn't fulfil all your responsibilities :P
[10:49] <cimi> tsdgeos, showing like 5 last comments by default
[10:49] <mzanetti> Saviq, hah... fair enough
[10:49] <cimi> tsdgeos, having a button with "show more"
[10:49] <cimi> etc
[10:49] <tsdgeos> cimi: that's a poor man solution
[10:49] <tsdgeos> i can't make a list view
[10:49] <tsdgeos> so i'll just give you 5 items
[10:50] <cimi> tsdgeos, I think what we have now is a poor man solution
[10:50] <tsdgeos> cimi: right, that's why we need a listview instead of a row
[10:50] <cimi> tsdgeos, showing the user an endless list of comments because we didn't plan to limit them
[10:51] <cimi> I don't think people care of reading 1000 reviews, the most recent ones are enough
[10:51] <cimi> I was wondering if there was a design for that, or we just ignored the problem
[10:52] <cimi> tsdgeos, anyway I did some work for limiting the delegate range, and the issue I had was calculating the limits when the listview is placed on screen
[10:52] <cimi> the first value ever I mean
[10:53] <tsdgeos> ok, i disagree with you that we should just drop this optimization and wait for a design change that makes us not care about the performance
[10:53] <tsdgeos> but we have work to do on filters
[10:53] <tsdgeos> i'll open a bug
[10:55] <cimi> tsdgeos, it's not dropped, it's on hold
[10:56] <cimi> tsdgeos, I have some local code, but couldn't figure out how to setup the initial displaymarginbeginning/end
[10:56] <Saviq> mzanetti, greyback, ideas for data to collect off of a phone that went into the no-input state could be useful, I initially thought stacktrace, but unity isn't hung, so not useful
[10:56] <cimi> tsdgeos, looks like Component.onCompleted is not the signal I want
[10:57] <Saviq> mzanetti, greyback, right now I'm suspecting either Qt's input machinery gone mad, or u-s-c unfocusing the session, only two that make sense to me?
[10:57] <cimi> I want the signal that is called when the Item is actually placed on screen in its final position
[10:57] <mzanetti> Saviq, debug prints, IMO
[10:58] <Saviq> yeah, we need a debug mode for that
[10:58] <Saviq> and many more debug calls in our code
[10:58] <cimi> only solution for that might be onYChanged but from outside the preview, which implies adding more API through the loaders just for this use case, and I wasn't happy with that
[10:58] <mzanetti> maybe even something that's auto-enabled in *-proposed images and disabled in stable ones
[10:58] <greyback> Saviq: it is that *nothing* in unity8 is getting events, or just edges?
[10:58] <Saviq> greyback, nothing
[10:58] <greyback> category logging ftw
[10:59] <mzanetti> greyback, the problem with that is, when the issue happens it's not enabled
[10:59] <Saviq> yeah we need to have a discussion about that platform-wide
[10:59] <greyback> mzanetti: sure, but with a small dbus interface we could enable at runtime
[10:59] <mzanetti> fair enough...
[10:59] <Saviq> might still be too late ;)
[10:59] <mzanetti> indeed
[10:59] <Saviq> I was surprised to see how much android logs all the time
[10:59] <mzanetti> yeah... IMO *-proposed should have debug prints enabled
[11:00] <mzanetti> it makes sense... really
[11:00] <Saviq> even stable should
[11:00] <Saviq> some in-memory circular buffer or something
[11:01] <Saviq> that gets read when an issue is reported
[11:01] <Saviq> otherwise we're too late
[11:03] <Saviq> dandrader, we're discussing bug #1491566, any ideas for debugging that?
[11:03] <Saviq> at least we should prepare a debug-enabled silo that people that can reproduce can install it
[11:04] <greyback> Saviq: I'd agree with you, either unity8's surface looses focus in USC, else Qt's input processing gets stuck in a bad state.
[11:05] <greyback> we've had to do filtering to fix up Qt's inputting with Mir's dirty input, perhaps something slips through still and breaks it
[11:14] <dandrader> well, at least on N9 times logging was hampering overall performance
[11:15] <dandrader> iirc
[11:18] <Saviq> sure, we'll need to measure the impact, but maybe we can hold an in-memory log of, say, a megabyte or something, one that's quite verbose, and grab its contents when a problem occurs
[11:18] <Saviq> something like that should not impact performance much
[11:18] <Saviq> with no I/O involved
[11:19] <Saviq> greyback, dandrader, could one of you please start a couple of MPs adding some debug logging to unity8 and u-s-c where you think we'd get most info on where the input goes, please?
[11:19] <dandrader> I think we could enable mir input logging in usc and unity8 (ie, qtmir)
[11:19] <Saviq> please please
[11:20] <dandrader> and qtEventFeeder logging in qtmir as well
[11:20] <dandrader> that should be enough to find out what's happening
[11:20] <Saviq> dandrader, sounds like you just volunteered?
[11:20] <dandrader> Saviq, it's not a matter of MPing, we just have to set the environment variables
[11:21] <Saviq> dandrader, oh even better, can you describe what needs to be done in the bug report?
[11:21] <greyback> dandrader: will some be very noisy though?
[11:21] <dandrader> greyback, it will
[11:21] <tsdgeos> Saviq: mzanetti: cimi: in GenericScopeView we have this showPageHeader property that noone uses and that complicates the code a bit by introducing a Loader, can i kill it?
[11:22] <cimi> tsdgeos, let me ready why we have that
[11:22] <cimi> read
[11:22] <greyback> Saviq: I fear we can realistically only debug log on every input event, which is very noisy
[11:22] <dandrader> Saviq, ok, I will try out on a device and then post the step-by-step instructions
[11:22] <cimi> tsdgeos, who wrote that?
[11:23] <cimi> and why we did?
[11:23] <dandrader> greyback, the idea is that whoever wants to reproduce this bug will enable the input logging. so I don't see the problem
[11:23] <Saviq> yeah, ↑
[11:23] <Saviq> someone who saw this on his device(s0
[11:24] <greyback> ah in that case, the env vars are exactly what that's for
[11:24] <Saviq> +Shift
[11:24] <Saviq> it should be made into a runtime switch
[11:24] <Saviq> env is so 1980s
[11:24] <greyback> +1
[11:25] <greyback> oh like totallay
[11:35] <tsdgeos> cimi: i did, because we used it another life :D
[11:35] <tsdgeos> food!
[11:45] <cimi> tsdgeos, well, then go for it :)
[13:53] <cimi> tsdgeos, for the filter loader, something around this? http://paste.ubuntu.com/12273227/
[13:54] <cimi> tsdgeos, similar to the preview widgets basically
[13:55] <tsdgeos> cimi: yaeh, leave out the triggered for now, not sure how we'll handle that
[13:55] <tsdgeos> and the expanded
[13:55] <cimi> tsdgeos, no expanded?
[13:55] <cimi> tsdgeos, I thought we would have some expanded filters like the calendar and such
[13:56] <tsdgeos> cimi: as far as i understand you either shown them or not
[13:56] <tsdgeos> there's no shown but unexpanded status we have in the preview widgets
[13:58] <tsdgeos> so no need to tell the inner widget if it's expanded, no?
[13:59] <cimi> maybe :)
[13:59] <cimi> tsdgeos, or we can leave it like showPageHeader for another life :)
[14:00] <tsdgeos> just don't add it for now
[14:00] <tsdgeos> we'll add it if we need
[14:04] <mterry> What are the current instructions for pocket desktop?  rc+proposed + Silo 0 + external hardware?
[14:04] <mterry> Saviq, ^
[14:04] <Saviq> mterry, silo0 isn't in a good state afaik, and it won't get better
[14:04] <Saviq> greyback, ↑?
[14:05] <greyback> mterry: best instructions are on the last pages of https://docs.google.com/document/d/1EtDf3MXVrTaW3xfPNUALYmKTNmTHxBAAtTmgnpRX-E4/edit#
[14:06] <Saviq> mzanetti, why you not in #ubuntu-mir? ;)
[14:07] <mzanetti> Saviq, dunno... didn't feel the urge :D
[14:07] <mzanetti> sometimes my bounces forgets all the channels and I have ro rejoin
[14:07] <Saviq> dumb bouncer
[14:07] <mzanetti> now I'm in #ubuntu-mir?  :D
[14:07] <Saviq> must've been a back-street boxer before and the brainz not working that well anymore
[14:15] <mterry> Whoops, got disconnected...  will repeat last messages just in case.  Ignore if you already saw them  :)
 greyback, ok, thanks.  That still suggests silo 0, so I'm uncertain how testable that is.  But it might get me somewhere
[14:15] <mterry>  Saviq, actually, do you happen to know which bits of silo0 aren't landed yet?  maybe I can just build those myself
[14:15] <greyback> mterry: why are you trying this?
[14:16] <greyback> it's just kept alive for demos, we're working on landing the bits in it properly
[14:17] <mterry> greyback, I wanted to help pick off some bugs, but just wanted to recreate setup first
[14:47] <dandrader> Saviq, your script tells me lp:unity8/overlay has a bogus tag
[14:47] <dandrader> Saviq, do you confirm that?
[14:47] <Saviq> dandrader, yeah I saw that, it decides it's bogus locally
[14:47] <Saviq> dandrader, but it's fine remotely
[14:48] <Saviq> and well, it's really bzr that's saying that
[14:48] <Saviq> dandrader, trunk has the same
[14:48] <dandrader> Saviq, so I should just ignore it, I guess?
[14:48] <Saviq> dandrader, yeah
[14:55] <dandrader> tsdgeos, got an easy one for you https://code.launchpad.net/~dandrader/unity8/stabilizeShellTestAgain/+merge/270188
[14:57] <tsdgeos> cool, will do on monday, early EOD for me today, going to the mountains for the weekend
[14:57] <tsdgeos> with forecast of rain
[14:57] <tsdgeos> :/
[14:57] <dandrader> tsdgeos, hmm, montains. sounds great
[14:57] <dandrader> minus the wheather forecast, naturally :)
[14:58] <tsdgeos> oh well it's 50% chance rain
[14:58] <tsdgeos> hoope we're lucky
[14:58]  * tsdgeos waves
[15:00] <Saviq> ltinkl, is it on purpose that reboot button is grey now?
[15:03] <ltinkl> Saviq: what branch are you running?
[15:03] <ltinkl> Saviq: but generall yes, it was a request from design IIRC
[15:04] <Saviq> ltinkl, I'm testing silo 14 which has your global shortcuts branch in it
[15:27] <dandrader> mzanetti, ping
[15:27] <mzanetti> dandrader, hey
[15:28] <dandrader> mzanetti, so greyback wants me to move the cursor image provider (and probably some other related stuff will have to go along with it, will see while I'm at it) from qtmir to unity8
[15:28] <dandrader> mzanetti, should it go to Unity.Utils or own module?
[15:29] <dandrader> I'm not sure what's the best or preferred option
[15:29] <mzanetti> dandrader, not sure either, but I would probably go with Utils... I feel we're having a bit too many plugins already
[15:29] <mzanetti> dandrader, had a discussion about this a while back with some people but we didn't really reach a conclusion
[15:30] <dandrader> mzanetti, which raises the questions: what's worse? a big module or several smaller ones? (I don't have the answer)
[15:30]  * greyback likes lots of little modules. Is modular :)
[15:30] <mzanetti> greyback, I am a bit concerned about loading times etc, but in general yes, modular is good
[15:30] <mzanetti> greyback, but then seeing that we have a bunch of plugins that only have like 2 lines of actual code ...
[15:31] <mzanetti> dandrader, you might want a MouseUtils? I assume we'll need those edgepush areas etc soon
[15:32] <mzanetti> although they could go to Gestures too probably...
[15:32] <greyback> I can't say without having some numbers on the topic. the searching the filesystem and symbol resolution does have a little cost, dunno if it's much in the grand scheme of things tho
[15:32] <mzanetti> greyback, it's not much... but once we have 100 plugins it's 100 times not much
[15:33] <greyback> which still may not be much ;)
[15:34] <greyback> I have no idea of the perf impact
[15:34] <mzanetti> dandrader, actually, use it's own module... makes it easier to reuse without pulling unity specific utils
[15:38] <mzanetti> dandrader, I just came by this: http://doc.qt.io/qt-5/qml-qtquick-mousearea.html#cursorShape-prop
[15:38] <mzanetti> dandrader, will this be supported?
[15:38] <dandrader> mzanetti, yes
[15:38] <mzanetti> awesomes
[15:38] <dandrader> mzanetti, but unfortunately not enough for us
[15:38] <mzanetti> really? what's missing?
[15:38] <dandrader> mzanetti, Qt's enumeration doesn't contain all the 8 different shapes we use for window resize
[15:38] <mzanetti> lol
[15:39] <mzanetti> had no idea it's that many
[15:39] <greyback> we can always define extra enums on top
[15:39] <mzanetti> can we extend?
[15:39] <mzanetti> doesn't sound hard to patch in, and we're in a better position of upstreaming things lately
[15:39] <dandrader> mzanetti, so had to add a Mir.cursorName API for that. but the two coexist fine
[15:39] <dandrader> mzanetti, thing is, Qt is all about multiplatform
[15:40] <mzanetti> sure...
[15:40] <dandrader> mzanetti, so I don't know if all those extra cursors make sense in other platoforms
[15:40] <mzanetti> but that doesn't mean only supporting the smalles common set
[15:40] <dandrader> mzanetti, might be Xcursor specific
[15:41] <dandrader> mzanetti, right
[15:44] <dandrader> greyback, about the extra enums, I looked at this possibility, but looking at Qt source code, on how it handles the cursorShape value, it doesn't seem possible
[15:44] <greyback> :(
[15:44] <greyback> I guessed it was just a number in the end
[15:45] <mzanetti> greyback, it's not that easy to register them for QML etc
[15:45] <greyback> mzanetti: they're still just numbers to qml tho, no?
[15:46] <mzanetti> greyback, right... you sure can use integers, but that's not really nice... if extended it really should be additional Qt.CursorShapeBlabla things
[15:47] <mzanetti> no?
[15:47] <greyback> well if we're extending, we should use our own namespace. Unity.CursorSomething ?
[15:48] <mzanetti> not if extending upstream... otherwise yes, but I thought that's what daniel does
[15:50] <greyback> true
[15:53] <mzanetti> gotta go
[15:53] <mzanetti> see you all on monday
[15:53] <mzanetti> o/
[18:40] <dandrader> greyback, still around?
[18:46] <mterry> Are bluetooth and mako supposed to be friends?  My BT keyboard isn't working so hot