[08:24] <tsdgeos> mzanetti: Stage.qml needs to die?
[08:24] <mzanetti> tsdgeos: still there? I was quite sure I deleted it
[08:24]  * mzanetti does
[08:25] <tsdgeos> do it in the one we kill the test :D
[08:26] <mzanetti> tsdgeos: yeah, sure
[08:29] <mzanetti> tsdgeos: pushed. thanks
[08:29] <tsdgeos> :)
[08:35] <Saviq> tsdgeos, do you remember why we said we don't want to export LC_ALL in our test env (bug #1301038)?
[08:36] <tsdgeos> Saviq: not really, i think it may have been lazyness :D
[08:37] <tsdgeos> Saviq: i need to load the fake plugin on the scope tool because DashApps
[08:37] <Saviq> tsdgeos, no, I think we really said "yeah, let's not" for some reason ;)
[08:37] <Saviq> tsdgeos, right, that
[08:53] <Saviq> mzanetti, can you do another run through tsdgeos's branch for the app plugin (fixed scope tool)
[08:56] <mzanetti> ok
[09:02] <tsdgeos> Saviq: https://code.launchpad.net/~allanlesage/unity8/autopilot-indicator-page-title-matches-widget/+merge/196991
[09:05] <mzanetti> hmm... the scope-tool seems to work here even without albert's last fix
[09:05] <mzanetti> where should I see any breakage?
[09:08] <tsdgeos> mzanetti: same crash as before, loads the unity.application plugin and gets ::quit'ed
[09:08] <tsdgeos> mzanetti: do you have scopes running?
[09:08] <tsdgeos> i.e. do you see the apps scope in there?
[09:10] <mzanetti> tsdgeos: no. nothing in there.
[09:10] <mzanetti> let me try
[09:10] <tsdgeos> mzanetti: start scope-registry
[09:10] <tsdgeos> and the smart-scopes-proxy thing
[09:11] <mzanetti> tsdgeos: not crashing here. also unity8 was only crashing when I started an app, which doesn't seem to be possible with the scope-tool
[09:11] <tsdgeos> mzanetti: it still imports Unity.Application
[09:12] <tsdgeos> which will end up creating the ApplicationManager singleton
[09:12] <tsdgeos> and crashing
[09:12] <tsdgeos> are you sure you're totally dist-upgraded?
[09:12] <mzanetti> yes
[09:13] <tsdgeos> mzanetti: so you are on the scope-tool it's showing the apps scope and it's not quitting?
[09:13] <mzanetti> tsdgeos: yes
[09:13] <mzanetti> tsdgeos: ah no... not the apps scope
[09:13] <mzanetti> only 10 others, like music, ebay and whatnot
[09:13] <tsdgeos> well
[09:13] <tsdgeos> that's not what i said you needed :)
[09:14] <tsdgeos> please get the apps scope
[09:14] <tsdgeos> and try again
[09:16] <tsdgeos> mzanetti: do you know the name of the apps scope package? maybe you don't have it installed
[09:17] <mzanetti> yeah... have the package... fighting with my internet connection. (my ISP is doing some work around here and seems it just killed the ipv6 routing
[09:17] <Cimi> Saviq, as I expected, Unity.Application for the OSK
[09:18] <Cimi> MacSlow, I have a workaround for the crash
[09:23] <Saviq> Cimi, right, that makes some sense
[09:25] <Cimi> Saviq, and... is there a solution for this?
[09:26] <Saviq> Cimi, coming
[09:29] <tsdgeos> mzanetti: why do we need the preload thing in xvfb?
[09:30] <tsdgeos> mzanetti: also we no longer have a something like qmluitests that actually shows all the windows?
[09:30] <tsdgeos> is that on purpose?
[09:31] <mzanetti> tsdgeos: huh? it should
[09:31] <mzanetti> tsdgeos: make testSomething should still show it
[09:31] <mzanetti> only make xvfbtestSomething doesn't
[09:31] <tsdgeos> mzanetti: but i mean one that runs them all
[09:31] <tsdgeos> i.e.
[09:31] <tsdgeos> make qmluitests
[09:31] <tsdgeos> runs all xvfbtestSomething
[09:31] <tsdgeos> while previously it ran all the testSomething
[09:32] <tsdgeos> would it make more sense to have qmluitests did what it did and the make xvfbqmluitests run all xvfbtestSomething ?
[09:34] <tsdgeos> mzanetti: am i making sense?
[09:39] <mzanetti> tsdgeos: re. got a phonecall too... sorry
[09:40] <mzanetti> tsdgeos: yes, I agree having a way to execute all without xvfb would make sense
[09:40] <mzanetti> tsdgeos: I'll look into it
[09:40] <tsdgeos> mzanetti: wahat about the ldpreload thing?
[09:41] <mzanetti> tsdgeos: that's required for nvidia cards.
[09:41] <tsdgeos> weird
[09:41] <tsdgeos> ok
[09:41] <mzanetti> tsdgeos: Saviq knows more about it
[09:45] <mzanetti> tsdgeos: ok. scope tool issue reproduced, fix verified & approved.
[09:45] <tsdgeos> mzanetti: :)
[09:47] <xnox> bregma: from silo5, i have tested unity for my changes. The u1 launcher is correctly gone and all indicators still load and indicator-sync is not pulled in (and indicator-sync got removed from the archive already)
[10:01] <Saviq> MacSlow, hey, is there something else ready for landing, other than https://code.launchpad.net/~macslow/unity-api/expose-notification-data-roles-to-qml/+merge/212581
[10:01] <Saviq> https://code.launchpad.net/~macslow/unity-notifications/mark-unsupported-examples/+merge/208113 ?
[10:01] <MacSlow> Cimi, tell me
[10:02] <Cimi> MacSlow, so it's the Unity.Application import
[10:02] <Cimi> MacSlow, if you comment it out from main.qml
[10:02] <Cimi> MacSlow, as well as OSKcontroller
[10:02] <Cimi> MacSlow, the app runs
[10:02] <MacSlow> Saviq, no... it's those three related bits I made ready
[10:03] <Saviq> MacSlow, hmm I only have two?
[10:04] <Saviq> MacSlow, or do you mean https://code.launchpad.net/~macslow/unity8/fix-notification-ap-test-assertions/+merge/212169 as well?
[10:04] <MacSlow> Saviq, no
[10:05] <MacSlow> Saviq, https://code.launchpad.net/~macslow/unity-notifications/modal-snap-decisions/+merge/212483 https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988  https://code.launchpad.net/~macslow/unity-api/expose-notification-data-roles-to-qml/+merge/212581
[10:07] <MacSlow> Saviq, there are things like https://code.launchpad.net/~macslow/unity-notifications/multiple-snap-decision-example/+merge/210638 and https://code.launchpad.net/~macslow/unity-notifications/mark-unsupported-examples/+merge/208113 but the are not "important" enough
[10:07] <greyback> ok, lesson learned: with tablet you can't start a long job in a screen session, detach, plug into power and leave it overnight, and expect it to be finished in the morning. Damn power management :)
[10:08] <MacSlow> Saviq, all other things (e.g. ComboButton-utilization) are not ready because I am/was caught up elsewhere
[10:08] <MacSlow> Saviq, that's the rough summary :)
[10:09] <MacSlow> Cimi, good to know I'll try that out
[10:09] <Saviq> MacSlow, yeah, fine, was just asking what to merge - the modal snaps are not ACK'ed, though, did we get a design ACK for it?
[10:10] <MacSlow> Saviq, I've attached a screen-cast to the bug filed by JohnLea I've never heard back from yet
[10:10] <Saviq> MacSlow, ok thanks
[10:10] <Saviq> MacSlow, connect the branch and the bug, please, though
[10:11] <Saviq> MacSlow, I mean to https://code.launchpad.net/~macslow/unity-notifications/modal-snap-decisions/+merge/212483
[10:11] <Saviq> actually, odne
[10:11] <Saviq> done
[10:11] <Saviq> MacSlow, ↑
[10:11] <MacSlow> Saviq, *cough.cough*  :) https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988
[10:11] <MacSlow> Saviq, see "Related bugs and blueprints" :)
[10:11] <Saviq> MacSlow, *cough.cough* https://code.launchpad.net/~macslow/unity-notifications/modal-snap-decisions/+merge/212483  :P
[10:12] <Saviq> MacSlow, that one wasn't linked
[10:12] <Saviq> aanyway
[10:12] <Saviq> that doesn't get in yet, then
[10:12] <MacSlow> Saviq, what link was missing then?
[10:13] <Saviq> the unity-notifications didn't link to the bug
[10:13] <MacSlow> crap
[10:13] <MacSlow> Saviq, so when will it be reconsidered?
[10:14] <Saviq> MacSlow, when someone reviews it :)
[10:14] <Saviq> MacSlow, I'll try and get John to look at the screencast today, though
[10:14] <MacSlow> Saviq, thx
[10:15] <MacSlow> Saviq, so now all three are linked to the bug
[10:15] <Saviq> MacSlow, k
[10:16] <MacSlow> Saviq, really thought I linked that too
[10:16] <Saviq> MacSlow, no worries
[10:18] <Saviq> MacSlow, just to confirm, works on the greeter, too?
[10:19] <MacSlow> Saviq, yes... even AP-tested
[10:20] <MacSlow> Saviq, so the modal-behaviour happens on the regular shell, but not on the greeter as per design
[10:20] <MacSlow> Saviq, oh... I didn't put that in the screencast
[10:23] <tsdgeos> elopio: are you doing the review of https://code.launchpad.net/~saviq/unity8/skip-bluetooth-on-manta/+merge/211834 ?
[10:24] <MacSlow> Cimi, I'll dive into it right after lunch
[10:24] <Cimi> MacSlow, thx
[10:25] <Saviq> MacSlow|lunch, ok, got ack
[10:33] <mzanetti> Saviq: so investigating the closing apps issue. its not because they're asleep but because upstart doesn't know them and we only stop through upstart. had a chat with greyback and we were thinking if we shouldn't start forcing people to move to upstart for starting things.
[10:34] <tsdgeos> mzanetti: i've had to merge+resubmit https://code.launchpad.net/~aacid/unity8/removeUnusedDashRendererProperties/+merge/212867 into https://code.launchpad.net/~aacid/unity8/removeUnusedDashRendererProperties/+merge/213997 because of a merge conflict can you do a qiuck re-review, re-approve?
[10:34] <mzanetti> Saviq: so far identified parties are: settings, qtc and autopilot (where AP doesn't seem of a problem cause it stops apps on its own)
[10:35] <mzanetti> tsdgeos: sure
[10:35] <greyback> Saviq: mzanetti as long as upstart can satisfy their requirements
[10:35] <greyback> if it doesn't, a workaround in unity-mir would have to suffice I guess.
[10:35] <mzanetti> other possibility would be to send the sigterm/kill/whatever ourselves whenever upstart fails to stop something.
[10:36] <Saviq> mzanetti, greyback, yeah, we'll force people to move to upstart ultimately, but that's not a short-term goal I'm afraid
[10:37] <Cimi> Saviq, what might Unity.Application start?
[10:37] <Saviq> mzanetti, greyback, so yeah let's close the window (as mardy asked) when upstart fails
[10:38] <mzanetti> ok
[10:44] <Cimi> Saviq, it workz!
[10:48] <Cimi> MacSlow|lunch, don't need you for now
[10:50] <dandrader> tsdgeos, I'm getting an empty dash even though I have an army of scope-related processes running. where should I start debugging? dbus?
[10:50] <tsdgeos> ouch
[10:51] <tsdgeos> dandrader: do you see the different scopes at least?
[10:51] <tsdgeos> or no scopes at all either?
[10:51] <dandrader> nothing
[10:51] <dandrader> so I flashed the device. all nice. then compiled new mir, platform-api, the "qt as mir compositor" qpa and unity8
[10:52] <dandrader> then I run that new unity8. all fine except nothing shows in the dash
[10:55] <tsdgeos> dandrader: you sure the merge is correct?
[10:55] <tsdgeos> i.e. all your unity imports are 0.2 and not 0.1?
[10:55] <dandrader> tsdgeos, yes
[10:59] <tsdgeos> dandrader: what does http://paste.ubuntu.com/7198177/ give you?
[11:02] <dandrader> tsdgeos, hmm http://paste.ubuntu.com/7198187/
[11:02] <dandrader> tsdgeos, so it's working, right? ^
[11:02] <tsdgeos> well it is kind of working yes
[11:03] <tsdgeos> but the fact you don't see anything
[11:03] <tsdgeos> it's not cool :D
[11:03] <Cimi> Saviq, tsdgeos z: 100 doesn't help
[11:03] <dandrader> tsdgeos, maybe there's some blunder in the unity8 qml code somewhere
[11:04] <tsdgeos> dandrader: yeah, can you show me the diff?
[11:04] <tsdgeos> Cimi: :/
[11:04] <Cimi> tsdgeos, your voice saying "that's bad" popped in my mind :P
[11:05] <tsdgeos> Cimi: want me to have a look at the code?
[11:05] <Cimi> tsdgeos, well
[11:06] <Cimi> tsdgeos, MainView { ... Notifications { anchors.fill: parent; z: 100 } }
[11:06] <dandrader> tsdgeos, lp:~dandrader/unity8/mirCompositorNew
[11:09] <mzanetti> dednick: hey. jfi: I reflashed my phone with the same image and the sim pin entry works again
[11:09] <mzanetti> dednick: if it happens again we should probably dig deeper tho
[11:09] <tsdgeos> Cimi: can you repro it in the desktop?
[11:09] <Cimi> tsdgeos, I'll try a test app
[11:10] <tsdgeos> Cimi: +1
[11:10] <dednick> mzanetti: hm. weird
[11:10] <mzanetti> dednick: yeah... until the reflashing there was absolutely no chance it bringing it up again
[11:11] <tsdgeos> dandrader: branching
[11:11] <mzanetti> dednick: note that this is on a read only phone with the stable released image (r250). so unlikely that I screwed up the image
[11:11] <dednick> mzanetti: yeah. must have been something funky going on with the indicator-network ofono dbus shizzle
[11:13] <tsdgeos> dandrader: so the whole code is the same in qml/Dash
[11:13] <tsdgeos> except a few Unity.Application -> Mir.Application
[11:14] <dandrader> yeah
[11:14] <tsdgeos> dandrader: is there any chance this is a bug in the compositor code you guys are doing?
[11:14] <tsdgeos> like not painting that area or something?
[11:15] <dandrader> in Shell.qml I essentially commented out all state stuff and removed the unity-mir hacks (InputFilterArea, OSKController)
[11:15] <dandrader> s/state/stage
[11:16] <dandrader> tsdgeos, ahahha, no. I see the new background. panel an launcher works fine
[11:16] <dandrader> tsdgeos, but you gave me I starting point. I will start adding more console.logs in the Dash code
[11:17] <dandrader> *a starting point
[11:17] <Cimi> tsdgeos, lp:~cimi/+junk/weird-header
[11:18] <tsdgeos> dandrader: good luck!
[11:18] <dandrader> :)
[11:20] <tsdgeos> Cimi: so that looks good? or not?
[11:20] <tsdgeos> ok, not
[11:21] <tsdgeos> wait
[11:21] <tsdgeos> you're transparent
[11:22] <tsdgeos> you're transparent
[11:33] <tsdgeos> Cimi: you had problems ssh'ing to the phone the other day, right?
[11:34] <Cimi> tsdgeos, nope
[11:34] <Cimi> tsdgeos, well, I had canonical sshebang to remove
[11:34] <tsdgeos> Cimi: so what did you remove exactly, i think i may be having the same issue
[11:36] <Cimi> tsdgeos, did you ever set up sshebang?
[11:36] <tsdgeos> Cimi: had Saviq help already
[11:36] <Cimi> ok
[11:42] <pete-woods> Saviq: https://wiki.ubuntu.com/SoftwareUpdates#Prompting
[11:51] <MacSlow> Cimi, is the expected outcome of commenting out the OSKController and the import Unity.Application in main.qml a white screen when the wizard is running during boot?
[11:51] <Cimi> MacSlow, nope
[11:51] <Cimi> MacSlow, that might be something else
[11:51] <Cimi> MacSlow, check debug
[11:52] <MacSlow> Cimi, where is that written to?
[11:52] <Cimi> tail -f /home/phablet/.cache/upstart/ubuntu-system-settings-wizard.log
[11:53]  * MacSlow tries again
[11:54] <Cimi> MacSlow, I'd also remove the file from config
[11:54] <Cimi> MacSlow, but it works now
[11:54] <Cimi> MacSlow, I don't need your help :)
[11:54] <Saviq> lol
[11:54] <Cimi> Saviq, well, still crashes with unity.application
[11:55] <Cimi> Saviq, but I'm waiting for that
[11:55] <Cimi> Saviq, how about this^ https://bugs.launchpad.net/unity8/+bug/1301309 ?
[11:56] <MacSlow> Cimi, so you see the notifications showing up then?
[11:56] <Cimi> Saviq, static color and // FIXME or // XXX
[11:56] <Cimi> MacSlow, I do
[11:56] <MacSlow> Dude!!!
[11:56] <MacSlow> Cimi, since when?
[11:56] <Saviq> Cimi, please fix, it's just white on white
[11:56] <Cimi> MacSlow, one hour ago
[11:56] <Cimi> MacSlow, I texted you here
 Saviq, it workz!
 MacSlow|lunch, don't need you for now
[11:57]  * MacSlow checks his logs
[11:57] <MacSlow> Cimi, really didn't see that
[11:57]  * MacSlow WTF's xhcat
[11:57] <MacSlow> Cimi, never mind then
[11:57] <Cimi> MacSlow, if you change nickname, maybe you miss highlight
[11:58] <Cimi> add MacSlow as a word to highlight
[11:58] <MacSlow> Cimi, no... it logs everything... and it would still trigger the icon-jiggle-dance... which it did not
[11:58] <Cimi> so you can be MacSlow|toilet and you'll get it :D
[11:58] <MacSlow> Cimi, usually yes
[11:59] <MacSlow> Cimi, so to recap... it was the position of the Notification {...} after all?
[12:03] <Cimi> MacSlow, no idea
[12:03] <Cimi> MacSlow, but works now
[12:03] <Cimi> MacSlow, flashed phone
[12:03] <Cimi> and other stuff
[12:05] <dandrader> tsdgeos, trying to understand the Dash code: What does DashContent show and what does ScopeItem show?
[12:09] <MacSlow> Cimi, I'm removing all the wizard.wifi related bits now... and go back to bug-hunting
[12:10] <elopio> tsdgeos: I am not, but I can take a look in a moment.
[12:11] <elopio> MacSlow: you pinged yesterday, right? Can I help you?
[12:12] <MacSlow> elopio, no... not right now... I might get to you later today with some AP-questions... right now bugs
[12:43] <elopio> MacSlow: ok
[12:48] <JohnLea> MacSlow, Saviq; hyia, what is the bug # of the bug you were discussing in the earlier conversation that you wanted feedback on?
[12:48] <MacSlow> JohnLea, the modal snap-decisions... bug
[12:48] <MacSlow> #
[12:48] <MacSlow> ...
[12:49] <MacSlow> JohnLea, https://bugs.launchpad.net/unity8/+bug/1285712 https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988
[12:49] <MacSlow> JohnLea, I've attached a screencast of the implementation in action
[12:49] <Saviq> MacSlow, actually not, JohnLea, bug# 1301682 and bug #1301685
[12:49] <MacSlow> JohnLea, but jouni also approved it
[12:50] <Saviq> bug #1301682
[12:50] <Saviq> JohnLea, ↑
[12:50] <MacSlow> Saviq, oh... and single button... that would be an interactive notification
[12:50] <Saviq> MacSlow, yeah, I commented on both
[12:51] <Saviq> MacSlow, but since the reworked spec is rather scarce on details, I asked for confirmation
[12:51]  * Saviq really thinks there's no point in having a single-button snap decision
[12:51]  * MacSlow agrees
[12:51] <Saviq> it should either be "Launch, Cancel", or actually nothing in the "OK" case
[12:52] <Saviq> that bfiller wrote about
[12:52] <Saviq> i.e. an interactive one
[12:52] <JohnLea> Saviq, MacSlow; I think bug #1301682 should be marked won't fix because it contradicts the queuing logic defined in section 4.2.2 of https://docs.google.com/a/canonical.com/document/d/1puQ9Z0yKqzsQ1VQ1OOBkxgp78iWGnAhAkFXWJFTWIrE/edit#heading=h.kr29xp2emoyq
[12:53] <Saviq> JohnLea, right
[12:53] <MacSlow> JohnLea, yup
[12:54] <JohnLea> Saviq, MacSlow; cool, added comment to bug and marked won't fix
[12:55] <JohnLea> Saviq, MacSlow; also re. single button notifications - if there is only one button in a notification it should actually be a clickable notification - no snap decision should have only one button
[12:55] <Saviq> JohnLea, yup
[12:55] <JohnLea> cool - does that answer your questions or was there something else?
[12:55] <Saviq> JohnLea, please comment on the bugs, that's all, we just wanted confirmation of the Won't Fixes
[12:56] <Saviq> tsdgeos, can you have a look at bug #1301871
[12:56] <JohnLea> Saviq, commented on bug #1301682 are there any other bugs you need me to look at?
[12:56] <MacSlow> JohnLea, yes... that's how I always viewed the reason which motivated the need for the "interactive notification"... keep the UI cleaner if possible
[12:56] <Saviq> JohnLea, not atm, thanks
[12:58] <Saviq> JohnLea, I can't change the status of the ubuntu-ux task, can you please mark it wontfix bug #1301685?
[12:59] <JohnLea> Saviq, woops, I marked it won't fix in the wrong project.  done now
[13:04] <mterry> Saviq, in silo 002, USC needs a rebuild.  Changes in mir/devel have broken it again and I updated it to match last night.   I think I need to do the same for unity-mir now
[13:04] <Saviq> mterry, yay for devel braches...
[13:05] <Saviq> mterry, just usc for now?
[13:05] <mterry> Saviq, yeah
[13:06] <Saviq> mterry, kicked
[13:07] <Cimi> Saviq, so basically what's the import path I should use now?
[13:07] <Cimi> Saviq, I'm confused because it still crashes at boot
[13:09] <tsdgeos> Cimi: lp:~aacid/unity8/application_manager_install_fix
[13:09] <Cimi> tsdgeos, but why is it crashing?
[13:09] <Cimi> tsdgeos, I'm running before shell
[13:10] <tsdgeos> unity.application calls ::quit
[13:10] <pete-woods> Saviq: https://code.launchpad.net/~unity-team/libusermetrics/file-based-infographics/+merge/214020
[13:10] <tsdgeos> if you're not a qmirguisomethingsomethingapplication
[13:10] <Cimi> ok
[13:10] <Cimi> tsdgeos, so how do I get a working oskcontroller and inputfilterarea?
[13:10] <Cimi> not-mocks
[13:11] <Cimi> I can always copy the plugins :D
[13:12] <tsdgeos> Cimi: you'd have to be a qmirguisomethingsomethingapplication or fix oskcontroller and inputfilterarea to not use the applicationManager
[13:12] <tsdgeos> or don't use them
[13:12] <tsdgeos> why do you need them?
[13:12] <tsdgeos> ah because you're a shell
[13:13] <Cimi> tsdgeos, Cimshell
[13:13] <Cimi> tsdgeos, pay respect, I have the power to show on your phone, when you boot, "Welcome to your Cimi phone"
[13:14] <pete-woods> Saviq: the camera MR https://code.launchpad.net/~pete-woods/camera-app/file-based-infographics/+merge/210573
[13:15] <pete-woods> (basically it just adds the click hook to say "I'm a source")
[13:16] <Saviq> Cimi, tsdgeos, yeah, the input area and friends should be a separate API I'd say
[13:17] <Cimi> Saviq, I can work on it
[13:18] <Cimi> Saviq, where can I put it? currently it's unity-mir
[13:20] <Saviq> Cimi, it needs to stay in unity-mir
[13:20] <Cimi> Saviq, so I can split Unity.Application and create a new module?
[13:20] <Saviq> Cimi, but needs to be a separate import, something along the lines of Unity.Input
[13:20] <Cimi> Unity.Cimi ?
[13:20] <Saviq> greyback, can you do a quick sanity check on what I said ↑?
[13:21] <Saviq> i.e. we want to be a shell with no app management
[13:21] <greyback> Saviq: Cimi: when we go the QtCompositor route, both will go away
[13:21] <greyback> the input filter a consequence of Mir being the compositor and input manager
[13:21] <Saviq> greyback, well, we'll need *some* input filter still
[13:22] <Saviq> greyback, since the keyboard might be a larger surface still than the input it will receie
[13:22] <Saviq> *receive
[13:22] <greyback> Saviq: with qtcompositor, all input goes directly into Qt's event loop
[13:22] <Saviq> greyback, i.e. it has key "popups" that go out of the keyboard rectangle
[13:23] <greyback> and we decide where those input events go to in QML
[13:23] <greyback> then the QML item that is the target of those events, delivers those events back to the mir client
[13:23] <greyback> Mir's input system is completely bypassed
[13:24] <Saviq> greyback, I understand that, but we need that "input-aware" item to be different than the surface item itself (sometimes)
[13:25] <Cimi> greyback, anyway guys, I need this soon :D
[13:25] <Cimi> Unity.Input or Inputs?
[13:25] <Saviq> Cimi, wait, though
[13:25] <Saviq> Cimi, there's no reason why you'd need to do that when you're the "shell"
[13:26] <greyback> Saviq: hmm then we need a way for a Mir surface to define its input area, in such a way that QML can make the correct decision where the input event should go
[13:26] <Cimi> Saviq, it crashes now
[13:27] <Saviq> greyback, yup
[13:27] <greyback> InputAreas are guessed by shell right now
[13:27] <Cimi> Saviq, upstart at boot before unity8
[13:27] <Saviq> Cimi, "crashes" with the protobuf error?
[13:27] <Cimi> Saviq, yeah
[13:27] <Saviq> Cimi, please ask #ubuntu-mir why that could be
[13:27] <Saviq> Cimi, that sounds like a bug
[13:28] <greyback> Saviq: as equivalent to what we have now, the shell will know the OSK surface, and we can have it not accept input events outside a certain geometry
[13:29] <greyback> and thus pass them to whatever is underneath
[13:29] <Saviq> greyback, yup, exactly what I meant
[13:30] <Saviq> mardy, hey, re: closing signon-ui window... it looks to me like something doesn't work correctly when we press "Back" in the UI, the surface goes away (blank), but the connection to Mir seems to remain, as we don't see the app closed or something
[13:31] <mardy> Saviq: I'm not sure how the Mir connection maps to Qt objects, but if it's bound to the QGuiApplication, that's expected: we are not destroying it
[13:32] <greyback> Saviq: that can be done, need to think about how to design it
[13:33] <Saviq> mardy, yeah, I think that's the problem, no windows doesn't mean no connection to mir → doesn't mean no app
[13:33] <greyback> OSKController can move into shell. Only reason it wasn't there is that it used window manager specific methods
[13:33] <Saviq> greyback, I'd think a kind of "input overrider" thing on surfaces
[13:33] <mardy> Saviq: so I think it's all correct, right? I'm calling "quitOnLastWindowClosed(false)
[13:34] <Saviq> mardy, so the process should go straight away?
[13:34] <greyback> Saviq: would be more pure-qml to have the actual surface Item itself decide whether to accept/reject events
[13:34] <Saviq> greyback, right, and "come back" if not accepted?
[13:35] <mardy> Saviq: no, the process stays for some (5, IIRC) seconds, then it quits
[13:35] <Saviq> mardy, ah, so you disable quitting on last window closed...
[13:35] <greyback> Saviq: if not accepted, qml will pass it to whatever is underneath
[13:35] <Saviq> greyback, well, yeah, that's what I meant
[13:36] <greyback> Saviq: ok, we're on same page
[13:36] <Saviq> greyback, only thing I'd be scared of in that case would be some input-sniffing attack angle
[13:37] <Saviq> greyback, i.e. maximized surface that doesn't accept input anywhere
[13:37] <Saviq> greyback, but maybe paranoid
[13:38] <Saviq> mardy, so yeah, that sounds like an issue, maybe we need to improve the QPA in that case (no windows → app gone), not my area of expertise, though...
[13:39] <greyback> Saviq: if it doesn't accept input anywhere, where is the sniffing? But yeah it could be abused. Wuld need shell to decide if requested input region is accepable or not
[13:40] <Saviq> greyback, doesn't accept, doesn't mean it doesn't listen
[13:41] <greyback> Saviq: I mean more an app would define a geometry: "this sub region of my surface accepts events, else doesn't" and shell would implement that input policy
[13:41] <greyback> so we don't trust app to make the accept/reject events decision, shell does it
[13:41] <Saviq> greyback, right, yeah
[13:42] <Saviq> greyback, ok, then now we're on the same page ;)
[13:42] <greyback> Saviq: good
[13:42] <Saviq> greyback, sounds a lot like window shapes in unity-2d....
[13:42] <greyback> Saviq: exactly
[13:42] <Saviq> that api was crazy, though :|
[13:44] <greyback> how else could it be done? You effectively sent a binary pixmap to the server, about as flexible as it can get.
[13:44] <greyback> we could be more strict, where any part of app that doesn't receive events, is also made transparent
[13:44] <greyback> so an app can't draw in a place, but let the input pass through it
[13:45] <greyback> s/but/yet/
[14:24] <mzanetti> zbenjamin: in case the fix works for you, feel free to leave a comment here: https://code.launchpad.net/~mzanetti/unity-mir/quit-manually-started-procs/+merge/214013
[14:24] <mzanetti> well, if it doesn't too
[14:24] <zbenjamin> mzanetti: did you also find a cause why it maybe did not accept my SIGTERM from QtC?
[14:24] <mzanetti> zbenjamin: no... seemed to work fine on the first try here
[14:25] <zbenjamin> mzanetti: weird maybe its related to SSH somehow, QtC starts the process over a SSH connection
[14:25] <mzanetti> zbenjamin: shouldn't... but we do some fancy stuff down there in the signal handlers
[14:26] <zbenjamin> mzanetti: once the new QtC version is out i'll maybe ask you to test it for yourself. I wrote a app that shows me when its receiving a SIGTERM and it did clearly not when i pressed the stop button in QtC
[14:26] <zbenjamin> mzanetti: i have no idea where to look atm maybe you can help there
[14:28] <mzanetti> zbenjamin: ok, sure
[14:28] <dandrader> tsdgeos, greyback: you won't believe what fixed the empty dash: http://paste.ubuntu.com/7198880/
[14:29] <mzanetti> wow...
[14:29] <greyback> whaaaaa?
[14:29] <dandrader> scary
[14:30] <greyback> was disappearingAnimationProgress being animated?
[14:31] <om26er> Saviq, Hi! Can you remove my name from 'Unity UI stand-up' attendants ? :)
[14:31] <Saviq> om26er, you're leaving us? :(
[14:31] <Saviq> ;)
[14:31] <om26er> hah :D
[14:31] <dandrader> greyback, well, its value changes when you slide the greeter away
[14:32] <om26er> Saviq, that was QUICK
[14:32] <Saviq> ;)
[14:32] <greyback> Saviq: can you join standup?
[14:33] <tsdgeos> dandrader: that is veeery weird
[14:33] <tsdgeos> there's maybe some calculation that breaks that?
[14:33] <greyback> kgunn: joining us?
[14:34] <kgunn> crap
[14:35] <Cimi> mhr3, can you ping tsdgeos and Saviq for standup?
[14:39] <Saviq> Cimi, in a mtg
[14:39] <Cimi> ok
[14:48] <zbenjamin> mzanetti: it does not fix the problem as far as i can see
[14:49] <mzanetti> zbenjamin: hmm... strange... so its a different one than the settings app has
[14:49] <mzanetti> zbenjamin: just to make the cross-check: open system-settings, open accounts. swipe both away. close accounts. return to system settings and try opening accounts again
[14:49] <mzanetti> does it come up?
[14:51] <zbenjamin> mzanetti: hm no, but i installed your package
[14:51] <mzanetti> ok... then I maybe messed up with the package :/
[14:51]  * mzanetti verifies
[14:52] <zbenjamin> mzanetti: i rebooted would that remove the package_?
[14:52] <mzanetti> no...
[14:52] <zbenjamin> ok good, not that there is some sort of default image restore on boot
[14:53] <zbenjamin> mzanetti: just verified from the commandline that the accounts.ui was still running
[14:53] <mzanetti> no, there isn't.
[14:54]  * mzanetti installs the package on another phone
[15:23] <mzanetti> zbenjamin: indeed.... installing that package on another phone doesn't fix it... seems I messed up somehow
[15:23] <zbenjamin> mzanetti: ok np
[15:24] <zbenjamin> mzanetti:lets test it tomorrow again, i'll go to training soon
[15:24] <mzanetti> zbenjamin: ok... I'll make sure to have a working package for you by tomorrow morning
[15:24] <zbenjamin> mzanetti: nice thx!
[15:47] <pete-woods> Saviq: https://ci-train.ubuntu.com/job/landing-013-1-build/4/console I don't really understand this build error - all I've done is add an unreleased version?
[16:03] <Saviq> tsdgeos, hey, I'd like you to look at bug #1300302 please
[16:08] <Saviq> mzanetti, a different fun one for you: bug #1300326
[16:09] <mzanetti> Saviq: that came in with new-scopes I think
[16:09] <Saviq> mzanetti, yeah, sure, that's around when it started... but not explained by it...
[16:10] <Saviq> mzanetti, only thing I can think of is new scopes being more processing-heavy and that surfaced the issue
[16:10] <mzanetti> might be true...
[16:10] <mzanetti> Saviq: I have a feeling its related to the thing dandrader had today
[16:10] <mzanetti> that smoothedanimation in shell.qml
[16:11] <mzanetti> I'll look into it
[16:11] <Saviq> mzanetti, coolz, thanks
[16:13]  * greyback early eod
[16:31] <mzanetti> hmpf... trying to reproduce the grey tint one, I found another one:
[16:33] <mzanetti> open an app, swipe it away from the left. you'll be in apps scope. go to the scopes scope, pull in the app from the right, swipe it away from the left again
[16:33] <mzanetti> you'll be in scopes scope (which is wrong) with the apps scope's header
[16:47] <MacSlow> tsdgeos, What's the difference between libqt5quick5 and libqt5qml5?
[16:47] <tsdgeos> MacSlow: qml is the language
[16:48] <tsdgeos> quick is the graphics
[16:48] <tsdgeos> i.e. blackberry uses qml but not quick
[16:48] <MacSlow> tsdgeos, ok
[16:48] <tsdgeos> they uses qml+cascades
[16:48] <tsdgeos> ok, you can still use qml+quick, but qml+cascades is the recommended way
[16:48] <mhr3> mzanetti, everyone tells me that header sucks, and will go away anyway
[16:49] <mzanetti> mhr3: strangle in this case the header is the only one doing the right thing :D
[16:49] <mzanetti> but yeah. I've been told so too
[16:50] <MacSlow> tsdgeos, I'm just asking as I have the impression I need to debug QtQuick's Image or Qt's Image to figure out the regresssion with the messed up icons when updating a notification.
[16:51] <tsdgeos> MacSlow: which problem do you have?
[16:52] <MacSlow> tsdgeos, when I update the icon (Image {...}) of a notification the element doesn't get correctly updated... although the reported source and sizes are correct
[16:53] <MacSlow> tsdgeos, I tried numerous things on the QML-side all without effect... thus I think this might be a bug introduced by the move from Qt 5.0 to 5.2
[16:54] <MacSlow> tsdgeos, I need to see what's happening behind the scene, when the source of an already created Image get changed
[17:01]  * MacSlow drops out for food
[17:08] <elopio> hey unity team. We need another small review here: https://code.launchpad.net/~allanlesage/unity8/dash-apps-visible-ordering/+merge/213913
[21:06] <tedg> bregma, So I'm looking at your upstart indicator-session patch.
[21:06] <tedg> bregma, I don't think that we can drop gnome-session support.
[21:06] <tedg> bregma, It does a lot more on the desktop than just logging out.
[21:08] <bregma> tedg, yes, I'm not suprized, my patch was mostly exploratory and not intended as a proper solution
[21:09] <tedg> I feel like we shouldn't be telling Upstart to end the session.
[21:09] <tedg> We should be telling Unity8 to do it.
[21:09] <tedg> So it can do "app management stuff" on all the applications.
[21:10] <bregma> tedg, I am open to better ways to get things working
[21:10] <tedg> Let's see if Saviq is up late :-)
[21:12] <tedg> There's an API that Unity7 uses to pop up the logout dialogs, no?
[21:12] <tedg> Is that something from gnome-session or something else?
[21:16] <Saviq> wtf?
[21:17] <tedg> Heh
[21:17]  * Saviq sleeps
[21:17] <tedg> Saviq, We're talking about how to logout in the Unity8 world
[21:17] <Saviq> you don't
[21:17] <tedg> i.e. who should indicator-session talk to.
[21:17] <tedg> On desktop
[21:18] <tedg> We can talk to Upstart and just bring the whole thing down, but it seems like Unity8 should orchestrate bringing down apps.
[21:18] <Saviq> so, being frank, /me is drunk now, please file a bug, and I'll get to it tomorra?
[21:18] <Saviq> afk
[21:19]  * tedg is trying to decide if being drunk will get him more or less of what he wants :-)
[21:36] <bregma> tedg, should upstart now be reponsible to shutting down Uniy 8 gracefully, along with everything else it starts in the session?
[21:36] <bregma> *not
[21:37] <bregma> let me rephrase: I would think upstart itself should be responsible for stopping what it started on session shutdown
[21:37] <tedg> Sure, and it will, but there could be things like grace periods.
[21:38] <tedg> For instance to give apps a chance to save one last time.
[21:38] <tedg> Those signals all go via the session management interface, which is the app manager in Unity.
[21:38] <bregma> I would expect upstart to ask Unity to shut down, which would then ask all its spawn to do their thing
[21:39] <bregma> in a nice, orderly and heirarchical fashion
[21:39] <tedg> Upstart only gives it 5 seconds to do so.
[21:39] <bregma> it takes 20 seconds to shut down and reboot my laptop, what is Uniy doing that takes that long?
[21:39] <tedg> It can't have a sophisticated conversation with the apps
[21:40] <bregma> anyway, can't upstart be configured to be more patient?
[21:40] <bregma> I want all things not unnatural to have a beautiful symmetry
[21:40] <tedg> Sure, and actually Unity8 does configure it longer than that because apport couldn't get stack traces in time :-)
[21:41] <tedg> But, I think it's the wrong place to bring down the session in an orderly way.
[21:41] <bregma> would systemd do a better job? *ducks*
[21:41] <tedg> Heh, not really. The init systems are roughly the same.
[21:41] <tedg> (in this regard)
[21:42] <tedg> I think we want Unity8 to tell upstart when it's ready to go so it can pop user interaction dialogs, etc.
[21:42] <tedg> Things that might happen on "human time" -- they suck, but eh, we have to work with those humans.
[21:43] <bregma> well, that's not going to happen before final freeze for 14.04
[21:43] <bregma> how about system("pkill unity8"); ?
[21:45] <tedg> Heh
[21:45] <tedg> I'd rather add an API that Unity8 just did "exit()" on.
[21:53] <tedg> bregma, Look at unity8-mir.conf, the stop conditions there make sense.
[21:56] <tedg> bregma, bug 1302213
[22:03] <tedg> bregma, In a nutshell, I think we can wait to see what Saviq says, but I'd rather do that or just call "stop unity8"
[22:03] <tedg> bregma, And let that bring down the sessions.