[08:34] <tsdgeos> Saviq: what do you think of https://code.launchpad.net/~aacid/unity8/dierfv ?
[08:34] <Saviq> tsdgeos, surprise, did we not use it in the end?
[08:35] <tsdgeos> Saviq: we were using this only for the screenshots thing
[08:35] <tsdgeos> in the old apps scope
[08:35] <MacSlow> tsdgeos, hm... that is odd... the "if"-issue
[08:35] <tsdgeos> MacSlow: it's what jenkins says :D
[08:35] <Saviq> tsdgeos, ah, Flow...
[08:35] <tsdgeos> Saviq: yep
[08:35] <MacSlow> tsdgeos, jenkins is my personal enemy ;)
[08:36] <Saviq> tsdgeos, now I remember, I even got to that conclusion when I first saw your MP, still confusing this with Journals ;)
[08:36] <Saviq> tsdgeos, yeah, +1 of course
[08:36] <tsdgeos> Saviq: he he
[08:36] <tsdgeos> Saviq: ok :)
[08:43] <tsdgeos> MacSlow: you can not reproduce locally?
[08:43] <MacSlow> tsdgeos, just trying... but thunderbird is messing up my system, thus everytihng is dog-slow
[08:44] <MacSlow> and exiting thunderbird takes its time too :)
[08:44]  * MacSlow just can't get the hang of mutt
[08:58] <Saviq> seb128, do you have plans to land ubuntu-system-settings into rtm? or should I talk to someone else?
[08:58] <seb128> Saviq, ken has been handling the rtm landing, I can do one but better to sync up with him first
[08:58] <Saviq> seb128, ok, will do
[08:58] <seb128> Saviq, plans we have yes, there are a stack of fixes that should go to rtm or ota1
[08:59] <Saviq> yup
[08:59]  * Saviq preps unity8 alone then
[08:59] <seb128> what fixes do you lan?
[08:59] <seb128> d
[09:08] <MacSlow> tsdgeos, I've fixed the if-issue... but still have to iron out a part of the dismiss-test (sync/confirmation notifications were not available when I initially worked on the swipe-to-dismiss branch)
[09:09] <tsdgeos> ok
[09:09] <MacSlow> tsdgeos, I'll mark my branch as "wip" for the time being.
[09:09] <Saviq> seb128, the accepted ones from the recent unity8 release https://launchpad.net/ubuntu/+source/unity8/8.01+15.04.20141107.2-0ubuntu1
[09:34] <seb128> Saviq, hey, could you look at the current comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1390643 and comment on what you think is the best approach between those suggested?
[09:40] <Saviq> seb128, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1390643/comments/3
[09:40] <seb128> Saviq, thanks
[10:05] <mzanetti> Saviq: hey, what happened to the fact that we only lock the screen when waking up, as opposed to locking it before going to sleep?
[10:06] <mzanetti> iirc you once said there's a branch fixing it
[10:07] <Saviq> mzanetti, there were some approaches, but none that we implemented yet
[10:08] <Saviq> mzanetti, not a problem on krillin, so lower prio
[10:08] <mzanetti> ah ok
[10:09] <mzanetti> interesting... why isn't it a problem on krillin? display waking up slower?
[10:09] <Saviq> mzanetti, yup
[10:13] <mzanetti> Saviq: may I assign the RTM ones to you? given you do the cherry-picks... https://bugs.launchpad.net/ubuntu-rtm/+source/qtmir/+bug/1351559
[10:14] <Saviq> mzanetti, yeah, I should've done that
[10:14] <mzanetti> no prob
[10:33] <seb128> Saviq, if you use a Binding{} in the other way around too, don't you create a binding loop?
[10:34] <Saviq> seb128, kinda, but it's quickly interrupted by if (old != new) in all the setters
[10:35] <seb128> Saviq, well, it makes a warning be printed on stdout
[10:35] <Saviq> seb128, so even if you get a warning, it's benign
[10:35] <seb128> or stderr
[10:35] <seb128> I don't like getting warnings ;-)
[10:35] <Saviq> seb128, yes, that's why we need a BidirectionalBinding { } ;)
[10:36] <seb128> when is that coming? ;-)
[10:53] <mzanetti> Saviq: is there something like that in the works yet?
[10:54] <Saviq> mzanetti, not really, we were considering it with dednick at some point
[10:54] <Saviq> seb128, patches welcome ;)
[10:55] <mzanetti> well, so far I have decent results with Binding {} from backend to ui, and using ui's onClicked handler to change the backend value
[10:55] <mzanetti> that's what I usually do in my apps
[10:55] <mzanetti> but I agree QML should make it somewhat easier
[10:56] <dednick> Saviq, seb128, mzanetti: there was something for that in the ubuntu-settings-components check sync branch, but seb didnt want a special component.
[10:57] <seb128> dednick, I didn't say I don't want a special component, but rather than it should be in the uitk
[10:57] <mzanetti> -1
[10:57] <dednick> https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1336715.check.sync
[10:57] <mzanetti> should be upstream Qt
[10:57] <seb128> mzanetti, that's "toolkit" for me
[10:57] <seb128> so +1 for qt directly
[10:57] <mzanetti> seb128: you said uitk :D
[10:58] <seb128> I didn't know if it makes sense for qt
[10:58] <seb128> but the more upstream/mainstream it can be, the better
[10:58] <dednick> hm. not sure if it makes sense for qt
[10:58] <mzanetti> I'd say yes... some sort of UiBinding {} component
[10:58] <dednick> http://bazaar.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1336715.check.sync/view/head:/Ubuntu/Settings/Components/signalbinder.h
[10:58] <Saviq> mzanetti, problem is you might need to do some reconciliation, especially in the case of floats and such, like which value should you decide on if both sides changed, what if one side is slow to apply etc.
[10:59] <mzanetti> right...
[10:59] <mzanetti> still I guess there could be something useful... if you need very special stuff you can do it the old way
[10:59] <mzanetti> but yeah... there's a danger of making the mistake the uitk does... trying to be too clever and in the end not being useful for anyone
[11:00] <Saviq> totally
[11:00]  * mzanetti thinks of some listitems
[11:02] <dednick> i could propose a branch for the uitk which includes the signal binder. i think the implmentations of the switch/check are to specific for uitk.
[11:08] <facundobatista> Hola
[11:49] <Saviq> mzanetti, hah, splash screens are not antialiased ;)
[12:02] <mzanetti> meh
[13:04] <Saviq> mzanetti, hum, is it right that music app seems to be exempt from lifecycle still?
[13:05] <mzanetti> yes
[13:05] <mzanetti> still no playing music from apps in ubuntu :/
[13:11] <Saviq> ah, playlist progression :|
[13:11] <Saviq> is what we're missing
[13:11] <Saviq> mzanetti, and yes, we know your feeling on our lifecycle ;P
[13:14] <mzanetti> it wouldn't be so bad if I would see any progress on the background stuff
[13:27] <mzanetti> dandrader: ping
[13:27] <dandrader> mzanetti, pong
[13:27] <mzanetti> dandrader: hey, having some weird issue with the EdgeDragArea. maybe it makes sense to you:
[13:28] <mzanetti> dandrader: so I start dragging at the right edge and move the finger all across the screen to wards left
[13:28] <mzanetti> 2 grid units *before* reaching the left edge, dragging goes to false
[13:29] <mzanetti> (not sure about the 2 grid units - its some half centimeter)
[13:29] <dandrader> mzanetti, enable debug logs for TouchRegistry and DDA and then show me the log
[13:31] <mzanetti> dandrader: that debug output is really useful :D
[13:31] <mzanetti> problem solved
[13:31] <dandrader> mzanetti, so, what was it?
[13:31] <mzanetti> enabled went to false
[13:31] <mzanetti> so it makes sense
[13:31] <dandrader> mzanetti, :D
[13:31] <mzanetti> kinda hard to figure otherwise
[13:31] <mzanetti> but seems you did a good job with that debug stuff
[13:32] <dandrader> glad you liked it
[14:20] <mzanetti> dandrader: hey, this report came in. do you think this could be anything related to missing input? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1391149
[14:21] <mzanetti> dandrader: if you think no, let's assign it to mterry, otherwise could you have a look?
[14:26] <dandrader> mzanetti, looks like it could be related to the TouchGate in Greeter.qml. But I would rather keep working on shell rotation as I'm on a tight schedule
[14:26] <mzanetti> dandrader: sure... just wanted to have some first assessment to know where to push it to
[14:26] <dandrader> mzanetti, I will add a comment there
[14:26] <mzanetti> thanks
[14:53] <tsdgeos> pstolowski:
[14:53] <tsdgeos> ping
[14:54] <tsdgeos> unping
[15:40] <tedg> Saviq, So it looks like qtmir is raising sigstop after the mir connection is setup, but it seems like that should be later, no?
[15:41] <tedg> Saviq, Like after notifications interfaces and other stuff U8 provides are setup?
[15:42] <Saviq> tedg, well, as I commented I think it'd be better, if possible, if the indicators tried to reconnect
[15:42] <Saviq> tedg, depends on the definition of unity8 'started'
[15:43] <tedg> Saviq, The problem is that it's not a "reconnect" issue for notification, but the bigger issue is pulse. QtMir is initializing Mir quicker than Pulse can get setup.
[15:43] <Saviq> and it's kinda tricky because we'd have to explicitly wait for all the services we know we're waiting on to say "yeah, we good, go!"
[15:43] <tedg> Saviq, We can't depend on pulse because the upstart job is an touch-specific thing :-/
[15:44]  * tedg hates on the ubuntu-touch-session package a bit
[15:44] <tedg> Saviq, Confused? You mean plugins or services?
[15:44] <Saviq> tedg, well, so us pushing the sigstop further could just mean we're hiding the other issue?
[15:44] <Saviq> tedg, plugins == services
[15:44] <Saviq> tedg, like the notifications service is a plugin
[15:44] <Saviq> everything is a plugin, really
[15:44] <tedg> Saviq, Ah, okay. That's confusing to me. Not sure why things shipped together need dynamic loading :-)
[15:45] <tedg> Saviq, So I was thinking just an idle function, when the mainloop gets idle then raise the SIGSTOP.
[15:45] <Saviq> oh I'm afraid that's gonna be far too late
[15:46] <tedg> Why?
[15:46] <tedg> It seems like that's when things have finished their work.
[15:46] <tedg> Keep in mind that it should happen faster if we stop the CPU from context switching to indicators and the such by removing them from competing for CPU.
[15:49] <Saviq> tedg, well, that's counter to the fact that ogra wants to start everything in parallel, as early as possible ;)
[15:49] <Saviq> tedg, because that would mean the UI is set up, the dash started and stopped drawing, things like that
[15:50] <Saviq> tedg, so you'd actually be able to start using your phone and only then would indicators show up (or well, they wouldn't at all, if you used the phone enough)
[15:50] <Saviq> tedg, as for "why plugins", all kinds of reasons
[15:50] <tedg> Generally the goal isn't to start everything at once.
[15:51] <tedg> You just want as many things as you have cores.
[15:52] <Saviq> kinda difficult to encode in upstart events
[15:52] <tedg> It seems to me that there has to be a point where the Unity8 mainloop goes idle.
[15:53] <tedg> Generally things like phases come out of the setup of the Upstart events.
[15:53] <tedg> Not officially, but causally. So for instance, we don't limit the indicators to a number, but start them after so that they end up staying out of the way.
[15:54] <Saviq> tedg, unity8's main loop (i.e. the one on the first thread) is actually Mir, not the Qt one, where all the dbus things happen
[15:55] <tedg> Ah, okay. So would it be better to put a signal from the U8 application object when it thinks that it's done loading plugins?
[15:56] <tedg> Or do they all delay their inits?
[16:01] <Saviq> tedg, it's not just about loading, we'd need each "interesting" bit to report when they're ready
[16:01] <Saviq> tedg, as you're interested when it actually registers the name on dbus, not earlier than that
[16:01] <tedg> Saviq, Sure, that's why I was asking if the init was delayed. Sounds like it is.
[16:03] <tedg> I really feel like we should be more honest in the Unity8 startup reporting to Upstart.
[16:03] <Saviq> tedg, so if pulse is the real issue, how would delaying "unity8 started" even help? by chance?
[16:03] <tedg> But it is looking to me like this isn't an "rtm sized" fix.
[16:03] <Saviq> tedg, I think we just need to be more granular actually
[16:03] <Saviq> tedg, each service should emit its own 'foo-started' signal
[16:03] <tedg> Saviq, Well it's just that indicators are getting started exactly at the same time as pulse.
[16:04] <tedg> Saviq, Almost any delay would help.
[16:04] <Saviq> tedg, well, yeah, but that's by chance, meaning that you could just as well put "sleep 2" in there...
[16:04] <tedg> Thinking we might have to override in ubuntu-touch-session until that pulse job can be pushed upstream.
[16:05] <tedg> Sure, but trying to fix the problem more than put a sleep in.
[16:05] <tedg> I think the "fixish" is just to override indicator sound to be "start on indicators-start and started pulseaudio"
[16:05] <tedg> But that can only be in touch, not desktop.
[16:06] <Saviq> tedg, sounds like a good idea to add an .override then?
[16:07] <tedg> Saviq, Yeah, I don't like that solution, but looking like the best right now.
[16:07] <tedg> Saviq, I would still like to move the indicators signal into post-start though if that's cool with you.
[16:07] <tedg> Saviq, It doesn't fix the bug, but seems more correct.
[16:07] <Saviq> tedg, sure
[17:10] <MacSlow> Cimi, what about https://code.launchpad.net/~macslow/unity8/icon-clipping-fix-1378417/+merge/241097 ... did you review it yet?
[17:11] <Cimi> MacSlow, looked like a no brainer
[17:11] <MacSlow> Cimi, sure... but you've not touched it :)
[17:11] <Cimi> MacSlow, if you cannot think of any possibly wrong cases, let's approve
[17:11] <Cimi> MacSlow, yeah sorry...
[17:11] <MacSlow> Cimi, np... that's why I asked :)
[17:33] <MacSlow> Cimi, thx