[08:28] <mzanetti> Saviq: you around yet?
[08:31] <Saviq> mzanetti, yup
[08:33] <mzanetti> Saviq: any hints on how to clip something to an Ubuntu Shape while still allowing mouse interaction?
[08:34] <mzanetti> couldn't really understand why it works in the popover's code tbh.
[08:34] <Saviq> mzanetti, UbuntuShape { source: ShaderEffectSource { sourceItem: foo } }
[08:34] <Saviq> rm
[08:35] <Saviq> image: ShaderEffectSource
[08:35] <mzanetti> right... that's what UbuntuShapeForItem does
[08:35] <Saviq> yeah
[08:35] <mzanetti> however, it does also "hideSource: true"
[08:35] <mzanetti> whcih is obviously needed for clipping
[08:35] <Saviq> mzanetti, yeah, but that's only visual hiding, not for input
[08:35] <mzanetti> oh really... I wonder why my code doesn't work then
[08:35] <mzanetti> because that's what I do
[08:35] <Saviq> mzanetti, it's not same as visible: false AFAICT
[08:36] <mzanetti> I had the same impression when doing the Launcher. but somehow it doesn't pick up input right now
[08:36] <mzanetti> well, I'll figure it
[08:36] <mzanetti> thanks
[08:36] <om26er> unity8 crashes for me whenever I open a music preview :/ bug 1240408
[08:42] <dednick> MacSlow, Saviq: https://bugs.launchpad.net/unity8/+bug/1237752 what's going on there?
[08:43] <Saviq> dednick, dunno :D
[08:43] <MacSlow> dednick, that's me having picked bugs to work on...
[08:43] <dednick> Why has it been set to ubuntu-settings-components ?
[08:43] <Saviq> MacSlow, dednick please sync, then :)
[08:44] <MacSlow> dednick, Saviq: I'm just trying to figure out what/where stuff is missing
[08:44] <dednick> :)
[08:44] <dednick> MacSlow: ubuntu-settings-components not in archive and not used by unity8 yet
[08:45] <MacSlow> dednick, I rather pick high/critical bugs in components I know... but there are none :)
[08:45] <dednick> sil2100: what is the status of ubuntu-settings-components landing in archive?
[08:45] <MacSlow> dednick, so this "bug" is rather a missing / unimplemented feature?!
[08:45] <Saviq> greyback, on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224
[08:45] <dednick> MacSlow: it's "half implemented", the impl is there, but it's not available yet.
[08:46] <Saviq> greyback, think we could post a custom event on the loop instead?
[08:46] <Saviq> greyback, maybe not now - but ultimately
[08:46] <Saviq> greyback, would rather not have unity-mir tied to unity8 that closely
[08:46] <greyback> Saviq: do-able I think yes
[08:46] <MacSlow> dednick, ok... removed myself then... and look for something else...
[08:47] <Saviq> greyback, feels like that'd be the cleanest?
[08:47] <dednick> MacSlow: ok. sorry about the confusion
[08:47] <dednick> i'll assign myself
[08:47] <greyback> Saviq: well if we drop SF support, is not thing something only unity-mir should worry about?
[08:47] <greyback> s/thing/this/
[08:47] <MacSlow> dednick, np... not your fault... the bug-description could be a bit more detailed :)
[08:48] <Saviq> greyback, I don't think unity-mir should "know" about what upstart requires of unity8
[08:48] <MacSlow> dednick, would be good if you could add some info there to avoid anyone else running into this assuming it's a plain bug
[08:48] <Saviq> greyback, after all we don't want unity-mir to be tied to unity8, if possible
[08:49] <Saviq> greyback, and unity-mir shouldn't just raise SIGSTOP 'cause unity8 needs it
[08:49] <dednick> MacSlow: well, now that i'm assigned hopefully nobody will try pick it up :)
[08:49] <MacSlow> dednick, crap... I can't get the bug-status back to "Triaged"
[08:49] <Saviq> greyback, sure, the $UPSTART_JOB check helps us there
[08:49] <greyback> Saviq: depends on who you should should be responsible for talking to upstart. Technically it is Mir who is notifying upstart, not unity
[08:49] <dednick> MacSlow: i've updated it.
[08:50] <MacSlow> dednick, ah ok... even better that way
[08:50] <Saviq> greyback, IMO technically it's unity
[08:50] <Saviq> greyback, it's a unity8 job, after all
[08:50] <dednick> just leaving it in progess so nobody steals
[08:50] <Saviq> greyback, unity just listens to Mir/unity-mir to know *when* to raise that
[08:50] <Saviq> greyback, ah wait
[08:50] <Saviq> greyback, stupid, we've not yet exec()'d
[08:51] <Saviq> greyback, so we won't get that event until then
[08:51] <Saviq> OTOH that's probably not such a big problem
[08:52] <greyback> Saviq: ok, thinking about it, it is upstart-specific, so shouldn't always be in unity-mir.
[08:52] <Saviq> greyback, yup
[08:53] <Saviq> greyback, aaaanyway
[08:53] <Saviq> greyback, 'tis good for now
[08:53] <greyback> yarp
[08:53] <Saviq> greyback, we need to bump the build dep on mirserver when we know what to bump it to
[08:53] <greyback> Saviq: actually, must test it with lightdm...
[08:53] <Saviq> greyback, how so?
[08:53] <greyback> Saviq: think lightdm using unity-mir.
[08:54] <greyback> though since I check the job name it'll probably be fine
[08:54] <Saviq> greyback, yeah
[08:54] <Saviq> greyback, it would actually make sense for lightdm to expect stop, too
[08:55] <Saviq> greyback, since we'll have maliit as a client there, too
[08:55] <Saviq> at some point at least
[08:56] <greyback> indeed
[09:04] <veebers> Saviq: ping
[09:07] <Saviq> veebers, pong
[09:08] <veebers> Saviq: hey re: your question in the MR for unlocking greeter, wanted it catch you before i was off for the night. Are you suggesting that the unity8 tests should use the same functions for unlocking the greeter/starting unity?
[09:08] <veebers> (to clarify)
[09:09] <Saviq> veebers, yes
[09:09] <Saviq> veebers, so that there's only one breaking point - that we'll know of 'cause our tests will fail if we break it
[09:10] <veebers> Saviq: yeah that's a good thought I like it. Right now the unity tests would need re-jigging (I'm not to sure how much off the top of my head) we could always have a single test that 'tests unlocking greeter' which uses those methods etc.
[09:11] <Saviq> veebers, shouldn't be huge I don't think
[09:11] <veebers> Saviq: but will hit that tomorrow and see if I can work it in
[09:11] <Saviq> veebers, yeah, cool o/
[09:13] <veebers> Saviq: but that shouldn't hold back that specific MR if doanac needs it right(unless you see any issues w/ it)? We/I can update the tests to use them after it's been merged
[09:15] <Saviq> veebers, ah no, yeah, not a prerequisite
[09:16] <veebers> Saviq: sweet, if I could bother you to comment approve if you're happy and I'll hit up doanac tomorrow and top approve if he's sorted too
[09:18] <Saviq> veebers, yeah, still need to read through
[09:20] <veebers> Saviq: understood. Thanks, I'm off for the night have a good one
[09:43] <Saviq> mzanetti, ping
[09:44] <mzanetti> Saviq: pong
[09:44] <Saviq> mzanetti, hey, can you please have a look at https://code.launchpad.net/~diegosarmentero/unity8/disable-ui-on-actions/+merge/190145 and confirm what I wrote in the comment
[09:44] <mzanetti> ack
[09:45] <Saviq> mzanetti, and if that's correct, let's just yank out the "block input" part from it
[09:45] <Saviq> to avoid breaking scopes and stuff
[09:51] <mzanetti> Saviq: hmm... not so sure you're right there
[09:51] <Saviq> mzanetti, if I'm not, then even better
[09:52] <mzanetti> Saviq: well... I'm not sure either. would need to see how it looks like on top of switching-previews
[09:52] <Saviq> mzanetti, didn't have time to do it proper
[09:52] <Saviq> mzanetti, it would conflict with switching-previews
[09:52] <Saviq> mzanetti, but that's ~ok
[09:52] <mzanetti> Saviq: as this one only wants to disable one preview, not all of them
[09:52] <Saviq> mzanetti, and then there's bug #1235430
[09:52] <mzanetti> there is no real overlay in switching-previews
[09:53] <Saviq> mzanetti, right, it's replaced on preview loaded?
[09:53] <mzanetti> not really, it's a underlay so to say
[09:53] <mzanetti> actually it's only the spinner as the dakened background is supposed to be there all the time
[09:54] <mzanetti> yeah... the variable height is another one... the openEffect won't do as it is
[09:54] <mzanetti> as the openEffect splits the background
[09:55] <mzanetti> hmm... might still look good
[10:04] <Saviq> mzanetti, no, it will look fine
[10:04] <Saviq> mzanetti, only there's a lot that needs to be answere d around dynamic height of the preview
[10:05] <mzanetti> first question: is it really dynamic or is it just another fixed height?
[10:05] <mzanetti> well, I'll take care about it. probably not today tho
[10:07] <Saviq> mzanetti, yeah no, of course
[10:07] <Saviq> mzanetti, I'd say dynamic - even if just because we don't know the height beforehand
[10:08] <Saviq> mzanetti, we don't know what preview will we get
[10:08] <mzanetti> Saviq: hmm.. we kinda do. i.e. the previewDelegateMapper will give us some preview that has some fixed height
[10:09] <Saviq> mzanetti, that's too late
[10:09] <Saviq> mzanetti, that's when the preview is already back
[10:09] <Saviq> mzanetti, not when we open the dash
[10:09] <Saviq> mzanetti, say if a preview takes 2s to generate
[10:09] <mzanetti> oh, is it
[10:09] <mzanetti> no...
[10:09] <Saviq> mzanetti, we open the dash straight away
[10:09] <Saviq> mzanetti, and wait for the preview to come back
[10:10] <Saviq> without knowing what type it's going to be
[10:10] <Saviq> and only then the mapper goes into play
[10:10] <mzanetti> hmm... but the type is mapped according to the filtergrid we're in, not according to the actual content response iirc
[10:11] <mzanetti> Saviq: yep, just checked, it queries the delegateMapper immediately
[10:11] <Saviq> mzanetti, that's wrong then
[10:11] <mzanetti> don't see why
[10:11] <Cimi> Saviq, on the issue with the inversemousearea for application grid
[10:12] <Cimi> Saviq, it might be that other mouse area are on top of it
[10:12] <Saviq> mzanetti, because we don't know what type of a preview the scope comes back with
[10:12] <mzanetti> Saviq: oh right... it uses previewData.rendererName
[10:12] <Cimi> Saviq, I did a test app and indeed mouse area can overlap and stop the inversemousearea to work
[10:12] <Saviq> Cimi, that's broken then
[10:12] <Cimi> Saviq, are you aware of a way of detecting, from inspector or so, that mouse areas are overlapping?
[10:13] <Saviq> Cimi, IMA should be the first to take any input - that's its whole purpose
[10:13] <Saviq> Cimi, please file a bug with your testcase
[10:13] <Cimi> Saviq, that should explain nic-doffay issue on search box dismiss kbd?
[10:14] <Saviq> mzanetti, wait
[10:14] <Saviq> mzanetti, we don't want Diego's branch on top of switching previews yet
[10:14] <Saviq> mzanetti, we need it for v1, we won't get switching previews in
[10:14]  * greyback bbiab
[10:14] <mzanetti> hmm... ok
[10:14] <Saviq> mzanetti, would've loved to, but it's just too late :/
[10:14] <mzanetti> I agree
[10:15] <Saviq> mzanetti, we might SRU it ;)
[10:16] <Saviq> mhr3_, should we be seeing "publisher" in app previews yet?
[10:16] <mzanetti> I probably should know what SRU means. but I don't
[10:16] <Saviq> mzanetti, Stable Release Update
[10:16] <mzanetti> ah
[10:17] <Saviq> mzanetti, but yeah, it's mostly for security fixes ;)
[10:17] <Cimi> Saviq, maybe we should start using prevent stealing more often?
[10:18] <Saviq> Cimi, why?
[10:18] <mhr3_> Saviq, no such field in our schemas, "copyright" is the closest i guess, still don't think it's filled in by click
[10:18] <Cimi> Saviq, because our shell is populated by mouse areas
[10:19] <Saviq> Cimi, so you don't want to be able to flick the shell any more?
[10:19] <Saviq> mhr3_, hmm bug #1226265 ?
[10:20] <Cimi> Saviq, come on, we don't need flicking
[10:20] <Cimi> Saviq, all results should stay in the window frame :)
[10:20] <Saviq> Cimi, file an ubuntu-ux bug! ;)
[10:21] <Saviq> oh jeez click previews are slow today :/
[10:21] <mhr3_> Saviq, ah, they're passing it as generic info hint, in that case it should work
[10:22] <Saviq> mhr3_, k
[10:22] <mhr3_> Saviq, i mean, if app previews display those :)
[10:22] <Saviq> mhr3_, that bug says it would
[10:24] <mhr3_> Saviq, i don't see it in single preview though
[10:31] <Saviq> mhr3_, me neither
[10:33] <mhr3_> Saviq, my guess is that it's cause app preview is misusing info hints and passes super-special-click-scope-only variants that are used to build the ui
[10:35] <Cimi> Saviq, actually
[10:35] <Cimi> Saviq, z index works in my testcase
[10:36] <Cimi> Saviq, I can put the inversemousearea on top
[10:36] <Cimi> Saviq, I can't in the dash
[10:36] <Saviq> Cimi, shouldn't happen anyway
[10:36] <Cimi> Saviq, you know how can I debug this in the dash?
[10:37] <Saviq> Cimi, IMA should be z: ∞
[10:37] <Cimi> Saviq, what about when you have two?
[10:37] <Cimi> two of them?
[10:37] <Cimi> (ima)
[10:37] <Saviq> Cimi, two of IMAs? dunno
[10:38] <Cimi> indeed
[10:38] <Cimi> we might have two in the dash
[10:38] <Saviq> Cimi, Cimi but only one active at any given time, afaik
[10:38] <Saviq> Cimi, either way, z-order shouldn't matter for them
[10:38] <Saviq> Cimi, please file a bug against uitk
[10:38] <Cimi> Saviq, I will but doesn't help to fix my bug
[10:39] <Saviq> Cimi, it does - 'cause people that know IMA will look at it
[10:39] <Cimi> Saviq, I can look at ima too
[10:39] <Cimi> Saviq, I can read c++, just cannot write it :P
[10:40] <Saviq> Cimi, please talk to Zsombor first
[10:50] <Saviq> mhr3_, grr you broke our autopilot tests on desktop ;P
[10:51] <mhr3_> Saviq, oh haven't you heard? ap-test-breaker is my job title now :P
[10:51] <mhr3_> also, you're welcome :P
[10:52] <mhr3_> Saviq, anyway, what did i do this time?
[10:55] <Saviq> mhr3_, we can't launch the fake apps
[10:55] <Saviq> mhr3_, so no Hud tests
[10:55] <Saviq> mhr3_, 'cause you "fixed" application:/// to not have full path
[10:55] <Saviq> mhr3_, granted, all that's broken anyway ;P
[10:56] <mhr3_> Saviq, so i guess ap reads the uris directly?
[10:56] <mhr3_> why doesn't it go via the regular shell.activateApplication route?
[10:57] <mhr3_> Saviq, also, if you revert it back you'll break the previews ;)
[10:57] <Saviq> mhr3_, because the desktop files don't exist on desktop
[10:58] <Saviq> mhr3_, and Scope::fallbackActivate bails at that point
[10:58] <Saviq> mhr3_, nah, I'm seeing if I can find an actual fix
[10:59] <mhr3_> actual fix is to have proper test environment
[10:59] <Saviq> mhr3_, care to enable mir on desktop? kthxbai
[11:01] <mhr3_> Saviq, i meant dropping a few .desktops in test data dir and pointing a few envvars to it
[11:01] <Saviq> mhr3_, ah well, except they're not really required
[11:01] <Saviq> mhr3_, but yeah, I get what you mean
[11:05] <Saviq> mhr3_, and maybe it's the safest bet now...
[11:06] <mhr3_> Saviq, need pointers how to set it up?
[11:06] <Saviq> mhr3_, nah
[11:06] <Saviq> we only really need the camera for now
[11:06] <mhr3_> k
[11:06] <Saviq> mhr3_, and it's really only about it _being_ there, not about the contents
[11:13] <Cimi> Saviq, we can enable disbar bottomswipe
[11:13] <Cimi> Saviq, line 62 of dashbar.qml
[11:17] <Saviq> Cimi, probably won't happen - we're getting rid of dash bar anyway
[11:17] <Cimi> Saviq, I know, but it's one liner :P
[11:18] <Saviq> Cimi, post v1, k?
[11:18] <Cimi> ok
[11:24] <Saviq> mhr3_, huh, actually it was as easy as fixing application:// → application:/// ;)
[11:25] <mhr3_> Saviq, you mean in the model?
[11:25] <Saviq> mhr3_, yeah
[11:25] <mhr3_> Saviq, then you broke the preview
[11:25] <Saviq> mhr3_, why? application:// is wrong
[11:25] <Saviq> mhr3_, application:/// is correct
[11:26] <mhr3_> Saviq, /// is correct if it continues with full path
[11:26] <Saviq> mhr3_, no
[11:26] <mhr3_> Saviq, yes
[11:26] <Saviq> mhr3_, NO
[11:26] <mhr3_> Saviq, YES
[11:26] <Saviq> mhr3_, no, because it doesn't support uppercase
[11:27] <Saviq> mhr3_, hostname part needs to be always empty
[11:27] <Saviq> mhr3_, bug #1231444
[11:27] <mhr3_> Saviq, ehm? application schema isn't defined to have any hostname
[11:28] <Saviq> mhr3_, it's not a correct url then
[11:29] <Saviq> mhr3_, when parsed with QUrl, the hostname part is downcased
[11:29] <Saviq> which is correct
[11:29] <Saviq> you can't just "omit" the / to say there's no hostname part
[11:29] <Saviq> the part after :// is always hostname
[11:32] <mhr3_> Saviq, in that case the app id should be considered the hostname, no?
[11:32] <Saviq> mhr3_, no it can't be
[11:32] <Saviq> mhr3_, 'cause it's meant to be case sensitive
[11:32] <Saviq> mhr3_, and hostname is not
[11:33] <mhr3_> you're making me read the rfc
[11:33] <Saviq> mhr3_, hostname is case insensitive, that I guarantee you
[11:33] <Saviq> mhr3_, but ok, fixing with XDG_DATA_HOME now
[11:39] <mhr3_> Saviq, ok, the application schema isn't exactly well defined according to the URI rfc, and that's why we introduced the appid schema, right?
[11:39] <mhr3_> but that doesn't change the fact how application schema is used
[11:40] <mhr3_> it's either application://[app_id] or applications://[/full/path/to/.desktop]
[11:56] <tsdgeos> lunch!
[11:57] <Saviq> mhr3_, https://code.launchpad.net/~saviq/unity8/add-ap-data/+merge/191382
[11:58] <mhr3_> Saviq, prepending to XDG_DATA_DIRS would be better
[11:59] <Saviq> mhr3_, hmm ok
[12:00] <mhr3_> Saviq, reason being that home is just one dir, you're likely to break something by changing it, data_dirs is a set of dirs
[12:00] <Saviq> mhr3_, mhm
[12:04] <Saviq> mhr3_, pushed
[12:05] <mhr3_> Saviq, sure you don't want to put something inside the .desktop?
[12:05] <Saviq> mhr3_, not needed atm
[12:05] <mhr3_> ok
[12:05] <Saviq> mhr3_, so don't want to
[12:06] <Saviq> mhr3_, it's just to trick Scope::fallbackActivate
[12:06] <mhr3_> approved
[12:08] <Saviq> mhr3_, I'll wait for ci to be happy
[12:08] <mhr3_> k
[12:09] <Cimi> Saviq, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238763
[12:10] <Cimi> Saviq, my nexus cannot handle 2560x … images
[12:10] <Cimi> can someone try this with nexus 10?
[12:10] <Saviq> Cimi, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1227783
[12:11] <Cimi> Saviq, ok, marking duplicate then
[12:16] <Saviq> Cimi, already done
[13:05] <tsdgeos> Saviq: why does it break append_hint ?
[13:06] <Saviq> tsdgeos, it breaks more I'm afraid
[13:06] <Saviq> tsdgeos, must be the lookup is broken somehow
[13:06] <Saviq> tsdgeos, anything that updates notifications
[13:06] <Saviq> tsdgeos, this is as far as I got http://paste.ubuntu.com/6245541/
[13:07] <tsdgeos> this is just fixing the autopulot, no?
[13:07] <tsdgeos> how did you find the append_hint is broken?
[13:08] <Saviq> tsdgeos, I ran the tests
[13:08] <Saviq> tsdgeos, but I can also see
[13:08] <tsdgeos> and they worked?
[13:08] <Saviq> tsdgeos, no they didn't
[13:08] <tsdgeos> the tests still don't pass here with that chang
[13:08] <tsdgeos> but because it can't find notification1
[13:09] <tsdgeos> not because anything else
[13:09] <Saviq> tsdgeos, did you install the modified unity-notifications?
[13:10] <tsdgeos> why would i need that for the notification1 to be found?
[13:10] <Saviq> tsdgeos, notification1 *are* all the notifications that are displayed - 0 is the placeholder
[13:10] <tsdgeos> ah
[13:10] <tsdgeos> obviously i do
[13:10] <tsdgeos> silly me
[13:10] <Saviq> tsdgeos, we're down to http://pastebin.ubuntu.com/6245556/
[13:10] <Saviq> 4 failures that I don't think are ap issues
[13:11] <Saviq> tsdgeos, scratch that, the urgency_order is fine, as I'd expect it
[13:12] <Saviq> tsdgeos, but none of the ones that *update* a notification are good
[13:13] <Saviq> tsdgeos, I expect the backend to be updating the wrong notification object
[13:13] <tsdgeos> ok
[13:13] <tsdgeos> i'll check
[13:14] <Saviq> or something like htat
[13:14] <Saviq> tsdgeos, you can use "examples" from unity-notifications to see what happens
[13:15] <Saviq> tsdgeos, but well, ap tests are probably even better, 'cause they'll tell you if stuff's fine
[13:15] <tsdgeos> sre
[13:16] <dednick> Saviq: my device keeps asking for ssh password lately. any way to get it to stop?
[13:16] <Saviq> dednick, ssh-copy-id
[13:17] <Saviq> dednick, probably ssh key failed to copy for some reason
[13:17] <pstolowski> charles, ping
[13:17] <tsdgeos> i hate autopilot
[13:18] <tsdgeos> why is it not using my compiled unity8 and instead using the system one
[13:18] <tsdgeos> don't we have code exclusively for that?
[13:18] <dednick> Saviq: thanks. worked
[13:19] <tsdgeos> ../../../builddir/install/bin/%s :_S ¿
[13:19] <charles> pstolowski, pong
[13:20] <tsdgeos> weird
[13:20] <dandrader> greyback, updated https://code.launchpad.net/~dandrader/ubuntu-keyboard/osk_rotation_lp1236489/+merge/190946
[13:20] <greyback> dandrader: cool, will take a look in 30mins or so
[13:22] <pstolowski> charles, hey! indicator-datetime-service crashes quite often for me on the desktop (almost daily); today it was https://bugs.launchpad.net/indicator-datetime/+bug/864530 but I'm not sure if it's the same every time. can I collect any more info to help fix it?
[13:22] <charles> pstolowski: !
[13:22]  * charles clicks
[13:22] <pstolowski> charles, sometimes it results in ~5 apport windows open in one session, but perhaps it's a separate issue with apport
[13:26] <Saviq> yeah, the weird "StateNotFoundError" is basically the same
[13:26] <Saviq> tsdgeos, ↑ as the notification times out due to not being updated
[13:26] <mzanetti> you know what's cool: with 3 fingers you can swipe the launcher, greeter and indicators simultaneously :)
[13:26] <tsdgeos> looking at it :)
[13:27] <tsdgeos> mzanetti: you have 3 fingers? that's what's cool
[13:27] <tsdgeos> ...
[13:27] <mzanetti> I have 10. believe it or not
[13:28] <tsdgeos> :O
[13:30] <dednick> sil2100: ping
[13:31] <sil2100> dednick: pong
[13:32] <mzanetti> MacSlow: git://anongit.kde.org/marble.git
[13:32] <dednick> sil2100: hi. just wanted to check on the landing status for ubuntu-settings-components. Is it in the pipeline?
[13:32] <mzanetti> MacSlow: branch qt5
[13:33] <MacSlow> mzanetti, thx
[13:34] <mzanetti> MacSlow: compile with "cmake <srcdir> -DQTONLY=1 -DQT5BUILD=1"
[13:34] <sil2100> dednick: didn't see any plans for it - is it required by anything right now? I can poke the landing guys if we can maybe prioritize it if needed
[13:34] <MacSlow> mzanetti, k
[13:36] <Saviq> greyback, standup?
[13:36] <charles> pstolowski|brb: that ticket is way too old, the backtrace is in code that doesn't exist anymore. Was that the link you intended to share, or do you have a newer crash report?
[13:36] <dednick> sil2100: it's not a major priority yet. Just didnt want it to be forgotten; will need it soonish.
[13:40] <Cimi> free karma https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414
[13:44] <Cimi> Saviq, I can spend some hours digging into this if you don0t have other high prio https://bugs.launchpad.net/unity8/+bug/1195349
[13:44] <Saviq> Cimi, sure, we're past high prio bugs, really
[13:45] <Cimi> Saviq, we still have a good list of unassigned https://bugs.launchpad.net/unity8/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field
[13:45] <Cimi> .has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[13:45] <Cimi> ops
[13:45] <Cimi> needs to shorten than
[13:45] <Saviq> Cimi, unassigned is fine, New is worse
[13:46] <Cimi> http://goo.gl/nd3NLw
[13:48] <Saviq> Cimi, that's ok, *we* are assigned by default
[13:48] <Cimi> https://bugs.launchpad.net/unity8/+bug/1238232
[13:48] <Saviq> Cimi, but we need to triage
[13:48] <Saviq> Cimi, yeah, that one's interesting :)
[13:48] <Cimi> quite funny :)
[13:51] <pstolowski> charles, hmm, right.. looking, I still have a crash file around
[13:53] <pstolowski> charles, this is my backtrace http://pastebin.ubuntu.com/6245754/
[13:54] <pstolowski> charles, I think ffi_call there made me think it was the same bt
[13:56] <charles> pstolowski: what a happy coincidence, seb128 and larsu and I were just talking about that bug
[13:57] <charles> that's been filed already, bug #1238737
[13:57] <charles> seb128 figured out the fix
[13:57] <pstolowski> charles, awesomeness! thanks
[14:01] <mzanetti> dandrader: ping
[14:01] <dandrader> mzanetti, pong
[14:01] <mzanetti> dandrader: I can reproduce the edge drag crash and have some findings. looks like a bug in DDA
[14:02] <mzanetti> dandrader:  http://paste.ubuntu.com/6245792
[14:02] <mzanetti> dandrader: now, I'm not sure how m_touchId works
[14:03] <mzanetti> dandrader: afaics you're only setting that in touchEvent_absent(). I assume when a new gesture starts
[14:03] <mzanetti> dandrader: but for some reason it can happen that the m_touchId is 0, while there is only one available touch point with id 1
[14:05] <dandrader> mzanetti, m_touchId is the id of the touch that is performing (or that we expect to perform) the gesture
[14:06] <dandrader> mzanetti, did you happen to have two fingers at the same time on the screen at any given moment?
[14:07] <nic-doffay> Saviq, ping
[14:08] <Saviq> nic-doffay, pong
[14:08] <dandrader> mzanetti, but in any case, we should get a "touch 0 ended" notice before it disappears from subsequent TouchEvents
[14:08] <dandrader> mzanetti, and that's what the code asusmes
[14:08] <dandrader> assumes
[14:09] <nic-doffay> Saviq, so I've moved the searchHistory ListModel to be a shared asset, however it appears that queries are not being added correctly because the search count never increase above 0. Any inclination what might be causing this?
[14:09] <nic-doffay> They are definitely being added to the same searchHistory.
[14:09] <dandrader> mzanetti, to make sure we are missing events you would have to log all touch events received
[14:10] <Saviq> nic-doffay, console.log() agrees with you?
[14:12] <mzanetti> dandrader: that's what I do
[14:13] <mzanetti> dandrader: got a touch event ...
[14:13] <mzanetti> dandrader: thats the first line touchEvent()
[14:13] <mzanetti> dandrader: oh... actually it's not... it's after the check for visible && enabled
[14:13] <mzanetti> so we _could_ miss something in there I guess
[14:15] <nic-doffay> Saviq, yeah.
[14:16] <Saviq> nic-doffay, and you're not getting any onCountChanged in the ListView?
[14:19] <nic-doffay> Saviq, negative.
[14:19] <Saviq> nic-doffay, so what changed between them working per-scope, and not working shared?
[14:20] <nic-doffay> Saviq, I moved the initialisation to Dash.qml.
[14:20] <nic-doffay> And passed it through to the page header.
[14:21] <mzanetti> dandrader: here's all: http://paste.ubuntu.com/6245873
[14:21] <mzanetti> dandrader: doesn't seem we're missing a touch event. more like the m_touchId gets confused when there are multiple touch es ongoing
[14:23] <Saviq> nic-doffay, I've no ready-made answer, if you show some code and tell me how it's not working, we can see
[14:23] <dandrader> mzanetti, so looks like we have a unit test already :)
[14:24] <dandrader> mzanetti, just feeding those events to DirectionalDragArea and seeing it crash
[14:24] <mzanetti> dammit... doorbell 3rd time in 10 mins
[14:24] <Saviq> kgunn, sorry, tab-based navigation in dash is TODO
[14:24] <dandrader> mzanetti, although your log doesn't say anything about the contents of those events, which is the interesting part
[14:24] <Saviq> kgunn, sorry if I made it confusing
[14:26] <Saviq> mhr3_, had to fix https://code.launchpad.net/~saviq/unity8/add-ap-data/+merge/191382
[14:26] <nic-doffay> Saviq, I figured as much. :/
[14:28] <Cimi> Saviq, https://code.launchpad.net/~unity-team/unity8/fix-1238232/+merge/191424
[14:29] <Saviq> Cimi, request a review from mterry please
[14:29] <Cimi> Saviq, done
[14:29] <mhr3_> Saviq, k, waiting for another ci run, or want me to re-approve?
[14:30] <Saviq> mhr3_, let's wait it out
[14:30] <mzanetti> dandrader|afk: I think I got it. there is touch event of type TouchEnd coming in as first thing for touch id 1. that's where you start a new gesture for touch id 1. but as it as a TouchEnd, it's not contained in the list of available touch points any more in the next run and boom
[14:30] <Saviq> mhr3_, or well, you can approve, I won't merge before the CI run anyway
[14:31] <mhr3_> Saviq, eek, still manual merging? :)
[14:31] <nic-doffay> Saviq, here's the branch, the diff is pretty small. https://code.launchpad.net/~nicolas-doffay/unity8/scope-search-refactor
[14:31] <Saviq> mhr3_, indeed
[14:43] <dandrader> mzanetti, awesome!
[14:43] <mzanetti> dandrader: https://code.launchpad.net/~unity-team/unity8/fix-1228336/+merge/191427
[14:47] <mzanetti> dandrader: hmm... that's really shitty to test
[14:47] <mzanetti> dandrader: as QTest::touchEvent doesn't let me generate a release only
[14:47] <mzanetti> and afaics I can't modify the QTouchEventSequence to remove the TouchBegin event
[14:48] <Saviq> tsdgeos, btw, file a QTBUG so we don't forget about ListView stealing focus?
[14:48] <mzanetti> wait... I might understood something wrong
[14:48] <tsdgeos> Saviq: ok, will do
[14:51] <Saviq> mzanetti, hey, so what's the status of https://code.launchpad.net/~diegosarmentero/unity8/disable-ui-on-actions/+merge/190145
[14:51] <Saviq> mzanetti, are we getting a MouseArea overlay or?
[14:52] <mzanetti> Saviq: well... what should I say... it won't work with switching-previews. but as we need to get this in before the other... just get it merged and I'll remove it again when merging the switching-previews
[14:52] <Saviq> mzanetti, ugh... can we get the overlay animating or not?
[14:53] <mzanetti> what do you mean with animating?
[14:53] <Saviq> mzanetti, fade in/out
[14:54] <Saviq> mzanetti, it was just blinking here for me, and AFAICT it couldn't be otherwise, 'cause it was created / destroyed with the preview itself
[14:54] <Saviq> mzanetti, that's what I wanted yo to confirm
[14:54] <Saviq> mzanetti, anyway, I got some time now, will look
[14:54] <mzanetti> Saviq: oh ok... got you wrong there
[14:55] <mzanetti> Saviq: right... the backend sends us a new preview object when something changes
[14:55] <Saviq> mzanetti, and that recreates the overlay as well
[14:55] <mzanetti> yes
[14:56] <mzanetti> Saviq: so I guess what you can do is to make this overlay opacity: 0 by default, and change that in component.onCompleted
[14:57] <Saviq> mzanetti, sure, but as soon as the new preview comes in
[14:57] <Saviq> mzanetti, it will disappear in one frame
[14:57] <mzanetti> true
[14:57] <Saviq> mzanetti, so yeah, we can fade in, but not out
[14:58] <mzanetti> but actually imho having such an overlay would look bad anyways. why not just disable the buttons?
[14:58] <Saviq> I'm fine with not showing it at all and just prevent people from causing mayhem in the backends
[14:58] <Saviq> mzanetti, we need to show that stuff is happening
[14:58] <mzanetti> +1
[14:58] <Saviq> mzanetti, but yeah, there's no design for long-running tasks while in preview
[14:59] <mzanetti> the action button that is causing the wait could have a spinner on it :)
[14:59] <mhr3_> ui fixes for bugs in scope :(
[15:00] <mzanetti> mhr3_: right..... fix the scope :P
[15:00] <mhr3_> wish it were that simple
[15:10] <Saviq> mzanetti, did you notice, btw, that LazyImage does not display the X on broken_image on the phone?
[15:10] <mzanetti> Saviq: nope didn't notice
[15:10] <Saviq> mzanetti, I think the SDK bails out on rescaling that image for some reason
[15:17] <Saviq> /food
[15:25] <mzanetti> dandrader: hmm... have a problem
[15:25] <mzanetti> dandrader: if I just enject a release in a test, it never ends up in the actual code
[15:32] <dandrader> mzanetti, install an event filter on the DDA and filter out the press
[15:48] <Saviq> mzanetti, you filed a bug about the private / no number issues?
[15:48] <Saviq> mzanetti, there's a mention of it on ubuntu-phone
[15:48] <Saviq> would be good to link a bug report
[15:53] <mzanetti> Saviq: done
[15:54] <Saviq> mzanetti, thanks
[15:58] <tsdgeos> Saviq: can't file the bug about LV and focus, since can't create a testcase :-/
[15:58] <tsdgeos> Saviq: http://pastebin.kde.org/pk7031r0r "works"
[15:58] <tsdgeos> i.e. doesn't shuffle the focus
[15:58] <Saviq> tsdgeos, put it in a FocusCope
[15:58] <Saviq> S
[15:58] <tsdgeos> just thhought that
[15:58] <tsdgeos> let me see
[15:59] <tsdgeos> nope
[15:59] <tsdgeos> http://pastebin.kde.org/p9gvvm4fz
[15:59]  * tsdgeos headdesks
[15:59] <tsdgeos> :(
[16:22] <mzanetti> dandrader: found another issue with this so I added a check that only the starting finger is processed and other fingers are rejected.
[16:22] <Cimi> is there a way to get the minimum real value available per platform?
[16:22] <mzanetti> dandrader: also updated tests
[16:22] <dandrader> mzanetti, if a second finger lands, you've to reject the gesture
[16:22] <mzanetti> dandrader: why is that?
[16:23] <mzanetti> I would not say so
[16:23] <dandrader> mzanetti, becuase it's a single-finger drag gesture
[16:23] <mzanetti> dandrader: sure... but why shouldn
[16:23] <dandrader> mzanetti, if you use two-fingers it's not a single-finger drag gesture anymore
[16:23] <mzanetti> dandrader: sure... but why shouldn't I be able to use one finger to swipe the left edge and another to swipe the right edge?
[16:24] <mzanetti> dandrader: I'm voting against that
[16:24] <Cimi> like Math.minium valid Real
[16:24] <Cimi> crap like that
[16:25] <dandrader> mzanetti, if you have one finger on the left edge, and one finger on the right edge. each DDA will get only one finger
[16:25] <mzanetti> dandrader: one DDA only works with one finger at a time
[16:25] <mzanetti> dandrader: yeah
[16:25] <dandrader> mzanetti, so there's no problem there
[16:25] <mzanetti> but prior to my branch one DDA can get confused by another
[16:25] <dandrader> mzanetti, but if you lay two fingers on the same edge, they both have to be rejected
[16:26] <mzanetti> dandrader: I wouldn't say so
[16:26] <mzanetti> dandrader: makes it harder to work with, for example if you accidentally touch something with your palm
[16:26] <mzanetti> dandrader: it's only the first finger that is used for the gesture detection anyways
[16:27] <dandrader> mzanetti, wanna join mumble. I'm tired of typing
[16:27] <mzanetti> dandrader: actually I don't want to discuss that either right now
[16:28] <mzanetti> this branch fixes the crash. I don't want to change something else in there
[16:28] <dandrader> mzanetti, ok
[16:40] <Cimi> Saviq, I'm on fire these days https://code.launchpad.net/~cimi/unity8/fix-1195349/+merge/191460
[16:40] <Saviq> lol
[16:42] <greyback> Saviq: I need a review, asap: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449
[16:43] <Saviq> greyback, yes sir
[16:44] <Saviq> greyback, so setting session to nullptr makes sure Mir does the right thing?
[16:44] <Saviq> or well, shared_ptr does
[16:44] <greyback> Saviq: yes, the shared pointer releases it's hold on the object, probably deleting it as it is last to hold it
[16:44] <Saviq> greyback, shall I test?
[16:44] <Saviq> greyback, i.e. should I see a difference
[16:45] <greyback> Saviq: alf_ has already in #ubuntu-mir
[16:45] <greyback> Saviq: <alf_> greyback: tvoss: verified ubuntuuitoolkit tests run fine, system fluid after tests
[16:45] <greyback> Saviq: but don't let that stop you
[16:45] <Saviq> will
[16:45] <Saviq> do
[16:45] <Saviq> greyback, anything in mir needed?
[16:45] <greyback> Saviq: nope
[16:46] <Saviq> cool beanz
[16:48] <bjsnider> i'm wondering if this still looks relevant: http://paste.debian.net/58424/
[16:48] <bjsnider> it's the patch that makes empathy work with unity's progress bar
[16:50] <Saviq> greyback, wow, we're down to below 100MBs RSS
[16:50] <Saviq> Albert did good with LVWPH :)
[16:50] <greyback> Saviq: yeah, we've done well
[16:51] <Saviq> 200MB already :D
[16:51] <Saviq> and counting ;)
[16:51] <Saviq> (before the fix)
[16:52] <tvoss> greyback, alan_g \o/
[16:54] <Saviq> shite, 600MB already
[16:54] <Saviq> and died
[16:55] <mzanetti> dandrader: actually you're right I guess...
[16:55] <Saviq> let's see - 90.3MB to start with
[16:56] <Saviq> yeah this is looking much better
[16:57] <Saviq> greyback, happroved!
[16:57] <greyback> Saviq: thank you
[16:57] <Cimi> Saviq, I finished my list of assigned bugs (apart the applications grid but it's on hold for now). Tomorrow I'm going to the office to see if there is feedback on something not reported that we want to fix, otherwise I can start pickup unassigned bugs
[16:58] <Saviq> greyback, hmm seems like we're still leaking somewhere now and again
[16:58] <Saviq> greyback, been going down to 87MB in between tests, ~10MB for a launched app
[16:58] <Saviq> after a few tests it's 99MB low, 110MB high
[16:59] <Saviq> so it seems like we've leaked one at some point
[16:59] <Saviq> greyback, but yeah, let's see where it settles
[16:59] <Saviq> greyback, still a huge improvement
[16:59] <greyback> Saviq: yep. The 2 screenshots may be held onto at times when they're not needed. Want to profile to see what else could be to blame tho
[17:00] <Saviq> we're still leaking smaller amounts constantly it seems
[17:00] <Saviq> but yeah, that's much appreciated all in all :)
[17:00] <Saviq> freakin' smart pointers :P
[17:00] <Saviq> not so smart anymore, are ya!
[17:01] <Saviq> 60 tests OK
[17:01] <Saviq> and we've leaked some 10MBs
[17:01] <Saviq> yeah!
[17:19] <mzanetti> Saviq: where is the code for the sim pin stuff?
[17:19] <mzanetti> the UI, that is
[17:34] <Saviq> mzanetti, Panel
[17:34] <Saviq> mzanetti, NotificationMenuItemFactory and start from there
[17:35] <Saviq> or well, that's it
[17:35] <Saviq> mzanetti, so not Panel - Notifications
[17:36] <mzanetti> me actually needs to enable the sim pin
[17:36] <mzanetti> :D
[17:37] <mzanetti> nooooo. qtbus not preinstalled :D
[19:33] <seb128> just as a warning, if some people have the unity8 saucy package installed, it might make your boot hang after today's update
[19:33] <seb128> if it does, remove /etc/init/boot-hook
[19:33] <seb128> boot-hooks
[19:42] <kenvandine> seb128, that makes me want to install unity8 on my desktop :)
[19:44] <seb128> kenvandine, lots of fun to debug boot hanging on plymouth, I'm glad stgraber helps
[20:24] <tedg> bregma, Okay, I can't build Unity.  I think it's because of my nvidia driver.
[20:24] <tedg> bregma, Can I disable the headless tests for the build?
[20:24] <tedg> bregma, Using bzr bd currently.
[20:24] <bregma> I know I usually do
[20:24] <tedg> bregma, How does one do that?
[20:25] <bregma> I just manually edit them out of the CMakeLists.txt and check that in temporarily
[20:25]  * bregma is a dirty cheater
[21:10] <tedg> bregma, Okay, this builds and works on my machine: https://code.launchpad.net/~ted/unity/nih-signals-complete/+merge/191457
[21:12] <bregma> tedg, if you stop the session dbus server, does it still cause unity-panel-service to call abort()?
[21:14] <tedg> bregma, Sure, wrong bug?
[21:14] <bregma> not necessarily
[21:14] <tedg> bregma, That's normal behavior for dbus clients.
[21:15] <bregma> the biggest problem is u-p-s emitting "(unity-panel-service:1686): Indicator-Appmenu-CRITICAL **: OMG! Unable to get a connection to DBus" on shutdown, which calls abort()
[21:16] <bregma> because the dbus daemon is shut down by upstart before yu-p-s is
[21:17] <bregma> however, it'sways near "(null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Connection was disconnected before a reply was received" in the log
[21:18] <bregma> which comes at process startup
[21:21] <bregma> either way, tedg, your proposed change is still correct and does the right thing, I just don't think it will fix the bug
[21:23] <tedg> bregma, That does seem odd considering dbus dies last.
[21:24] <tedg> bregma, Is that still happening?  It could be that it was starting too fast for dbus.  That was an issue in the dbus job.
[21:27] <bregma> I haven't see it duped since last week
[21:28] <bregma> MP approved anyway
[21:28] <tedg> Hopefully they're both fixed :-)
[21:31] <bregma> let's hope