[06:04] <jibel> there is a regression in unity/compiz with latest updates ( +13.10.20130920-0ubuntu1) bug 1229540
[08:46] <veebers> mzanetti: hey, who would be a good person to talk to re: the dash and scopes? I'm introspecting it and can't tell which scopes are 'enabled'. I.e. the social.scope details state enabled, but I can't see it on the phone (only have 4 options)
[08:49] <mzanetti> veebers: hmm... mhr3 perhaps
[08:49] <mzanetti> veebers: but let me have a look in the code
[08:50] <veebers> mzanetti: awesome, much appreciated
[08:50] <mzanetti> veebers: you should be able to get the amount of loaded scopes with dashContentList.count
[08:51] <mzanetti> veebers: and in the delegate you can get the scope.id I'd say
[08:52] <veebers> mzanetti: hmm, that might give me the count, but not which ones are enabled. I.e. I see the QQuickLoader with scopeId: "social.scope" has the properties: isLoaded(True), enabled(True), active(True)
[08:53] <veebers> but I can't tell from the introspected details if it's available or not (i.e. the social scope isn't available on the phone, I actually have Music, Home, Apps and Videos)
[08:53] <mzanetti> veebers: hm... isn't that enough?
[08:53] <mzanetti> veebers: no... but in that case it won't show up in the loader either
[08:53] <veebers> mzanetti: hmm, then why can't I swipe to it? perhaps my settings are borked?
[08:54] <mzanetti> veebers: huh?
[08:54] <mzanetti> so it shows up on the desktop, but you still can't swipe to it?
[08:56] <veebers> mzanetti: hmm, actually
[08:56] <veebers> mzanetti: sorry I think I've lead you and myself astray
[08:56] <veebers> I've gotten the logs between what's running on the phone and what I have running on my desktop :-\
[08:56] <mzanetti> ok
[08:56] <veebers> mzanetti: really sorry about that. Perhaps I'll have an actually question tomorrow. But for now I got that _all_ wrong
[08:57] <mzanetti> veebers: come on... no worries about that
[08:57] <mzanetti> happens
[08:57] <veebers> mzanetti: cheers
[09:11] <jibel> Could anyone have a look at bug bug 1229540, please
[09:11] <jibel> this is a recent regression
[09:11] <jibel> asac, ^
[09:15] <dholbach> hiya
[09:15] <dholbach> did anyone else notice apps like primarily firefox and thunderbird being extra slow since last week?
[09:16] <seb128> Trevinho, bregma, other compiz hackers: ^
[09:30] <asac> jibel: thats on desktop?
[09:30] <jibel> asac, yes
[09:35] <dholbach> jibel also filed bug 1229540, which I encounter as well
[09:35] <jibel> dholbach, I confirm the slowness on intel too
[09:36] <dholbach> it takes up to 3-4 seconds when clicking on a folder in thunderbird
[09:36] <jibel> especially transitions between windows, dash, alt-tab
[09:38] <jibel> it's difficult to measure responsiveness with an application that heavily relies on network
[09:39] <dholbach> sure, this is more gut feeling than anything scientific
[09:50] <seb128> dholbach, jibel: https://bugs.launchpad.net/compiz/+bug/1228352 and https://code.launchpad.net/~townsend/compiz/fix-auto-vp-switch-0.9.10/+merge/186881 seem to be the "super doesn't work on other workspace" issue you discussed earlier
[09:51] <seb128> it's fixed in trunk
[09:51] <seb128> so I guess we need another compiz landing
[09:51] <jibel> seb128, thank you
[09:51] <seb128> yw
[09:52] <dholbach> thanks seb128!
[09:58] <Saviq> pstolowski, hey, here's what should get you going with the invalidation https://code.launchpad.net/~unity-team/unity8/scope-isactive/+merge/187179
[09:59] <Saviq> pstolowski, feel free to just push to the same branch
[10:02] <pstolowski> Saviq: awesome, thanks!
[10:02] <pstolowski> mhr3: ^
[10:02] <Saviq> pstolowski, tested, too! ;)
[10:05] <mhr3> Saviq, are all those test changes desired/required?
[10:05] <mhr3> or mixed up branches?
[10:05] <Saviq> mhr3, cleaned up a little
[10:05] <Saviq> mhr3, if you look at it it's just moving stuff around
[10:05] <mhr3> very well, just wanted to check
[10:06] <mhr3> i'll merge it with my searchInProgress branch, don't want conflicts in it later
[10:06] <Saviq> mhr3, sure, just do whatever you want with it
[10:07] <Saviq> mhr3, treat as your own :D
[10:07] <mhr3> Saviq, like `bzr rm *`? :)
[10:07] <Saviq> mhr3, try doing that remotely on my copy!
[10:07] <mhr3> hmm, challenge accepted!
[10:07] <mhr3> don't forget you're running my code
[10:07] <mhr3> :)
[10:34] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/switching-previews/+merge/186991
[10:34] <Saviq> mzanetti, WiP?
[10:34] <mzanetti> Saviq: not any more
[10:35] <Saviq> mzanetti, could you please get design ACK for that? I feel, for one, that we need a bigger spinner
[10:36] <Saviq> and/or maybe darken the background while we're waiting
[10:36] <mzanetti> Saviq: I noticed that ApplicationsFilterGrid is not used any more. and in general the Dash directory contains a lot of unused legacy stuff
[10:36] <Saviq> mzanetti, you sure it's not used?
[10:37] <mzanetti> Saviq: yeah... just in one test
[10:37] <Saviq> mzanetti, right, it's using the generic one
[10:37] <mzanetti> yep
[10:37] <Saviq> mzanetti, well, generally there's quite some cleanup that needs to happen around that indede
[10:37] <Saviq> indeed, even
[10:38] <mzanetti> yep. and I'm afraid testing of the whole scope thing is not good enough either
[10:38] <mzanetti> which is why my branch doesn't really contain a test for this
[10:38] <mhr3> we'll really need to setup a test scope and have some tests talk to it
[10:38] <mzanetti> it would require a lot of mocking and
[10:39] <Saviq> mhr3, +1
[10:39] <mzanetti> yeah... what mhr3 said
[10:39] <Saviq> mzanetti, btw, could we get a spinner on first preview open?
[10:39] <mzanetti> Saviq: isn't it there?
[10:39] <Saviq> mzanetti, when you tap on "More suggestions", it just sits there
[10:40] <mzanetti> right... problem is, that this is triggered by a activate() on the item which is supposed to run the app
[10:40] <mzanetti> so in QML I don't have a way to know if there's a preview coming up
[10:40] <mzanetti> the scopes items would need an additional property "activatable" or whatever so it can trigger the correct signal
[10:41] <mzanetti> => the spinner on first preview only shows up onPressAndHold (as I know a preview is coming up)
[10:41] <Saviq> mzanetti, well, or we just put up a spinner on activate()
[10:41] <Saviq> mzanetti, and drop it when anything comes back
[10:41] <mzanetti> just on top of the other stuff?
[10:41] <mzanetti> would look quite bad imho
[10:41] <mhr3> mzanetti, all taps should do previews (minus apps)
[10:42] <mzanetti> mhr3: in all scopes?
[10:42] <Saviq> mhr3, minus Online Videos, too, atm
[10:42] <mhr3> mzanetti, Saviq, hm?
[10:42] <mhr3> mzanetti, in all afaik
[10:42] <Saviq> mhr3, oups, it seems to do both, actually
[10:43] <Saviq> mhr3, yeah, I tap on an item in Online, get a preview, and soon thereafter the web browser
[10:43] <mzanetti> Saviq: really... just tried here... I only get the browser onClick
[10:43] <mhr3> Saviq, then it's broken
[10:43] <mzanetti> oh wait
[10:43] <mzanetti> its broken indeed. first click behaves correctly
[10:43] <mzanetti> the others not any more
[10:44] <davmor2> morning guys I have a bit of an issue with the commercial apps that I am porting to Unity in that the installed apps seem to be showing up twice in the dash http://ubuntuone.com/3YJYgeuXb9jN9IYwkQwzLm
[10:44] <mzanetti> actually. only once you trigger a preview manually with longpress.
[10:44] <mzanetti> after that it's broken and does both
[10:44] <davmor2> to saucy rather than unity even
[10:44] <mzanetti> mhr3: ^
[10:45] <Saviq> davmor2, known bug, in fixing
[10:45] <mhr3> Saviq, it is?
[10:46] <Saviq> mhr3, I saw a branch...
[10:46] <davmor2> Saviq: fantastic do you have a bug number I can subscribe to so I can retest once it is fixed please
[10:46] <mhr3> davmor2, where are the .desktop files?
[10:46] <Saviq> mhr3, davmor2 actually bug #1225387
[10:46] <Saviq> Fix committed
[10:47] <Saviq> or released, even
[10:47] <davmor2> mhr3: /usr/bin/applications
[10:47] <mhr3> that one was because of click scope
[10:47] <mhr3> so not relevant to this
[10:47] <Saviq> ok /me shuts up
[10:47] <davmor2> sorry /usr/share/applications even
[10:48] <davmor2> Saviq: this is desktop commercial apps vs click apps
[10:48] <mhr3> davmor2, can you pastebin output of `libunity-tool -s /usr/share/unity/scope/applications.scope -q moves - r`?
[10:48] <mhr3> -r
[10:48] <mhr3> not - r
[10:49] <davmor2> mhr3: scope or scopes?
[10:49] <mhr3> scopes indeed
[10:50] <davmor2> mhr3: I'll just install libunity-tool first then it might work better then D'oh
[10:50] <mhr3> -tools :)
[10:51] <mhr3> is the pkg name
[10:52] <davmor2> mhr3: http://paste.ubuntu.com/6149541
[10:53] <mhr3> are you fully updated?
[10:53] <mhr3> anyone, once again
[10:53] <mhr3> plus you're missing the "-q moves"
[10:53] <davmor2> D'oh
[10:54] <Saviq> mhr3, mzanetti, so we can then assume that, except for running and installed apps, everything else will give us a preview?
[10:54] <mhr3> Saviq, you shouldn't assume, you should request a preview
[10:54] <davmor2> mhr3: http://paste.ubuntu.com/6149559
[10:54] <Saviq> mhr3, oh?
[10:54] <mzanetti> hmm... I'm not really sure if that will be true forever
[10:54] <davmor2> mhr3: I updated this morning let me reboot incase that fixes anything
[10:54] <Saviq> mhr3, thought it was the scope that will come back with a preview on activation
[10:55] <mzanetti> Saviq: yeah. that's what's happening now
[10:55] <mhr3> davmor2, nah, it's fine, it was the missing param
[10:55] <Saviq> mzanetti, yeah, I though we'll be continuing with that
[10:55] <Saviq> t
[10:55] <Saviq> brb
[10:55] <mhr3> Saviq, that's just an old "hack"
[10:55] <mhr3> the ui should request the preview, then you get proper signals etc
[10:55] <mzanetti> Saviq: the problem with that is that we don't have a chance to know if a preview will come up or not
[10:56] <mzanetti> hence we can't really display the ActivityIndicator
[10:56] <mhr3> that's why you should request a previe
[10:56] <mhr3> w
[10:56] <mhr3> if you do, you know it will come up
[10:56] <Saviq> mzanetti, of course
[10:56] <davmor2> mhr3: Right so I'm up-to-date and rebooted and it is still the same so phew at least you are not wasting your time :)
[10:56] <mhr3> well... or an error
[10:56] <Saviq> mzanetti, mhr3, I'm game with that
[10:57] <mzanetti> mhr3: but I'm still not convinced that we should do some if(name != applications) hack
[10:57] <mhr3> mzanetti, better solutions welcome
[10:57] <mzanetti> somehow the scope backend should tell us if this is supposed to be launched or not
[10:57] <mzanetti> as everything else is dictated by the backend too
[10:58] <Saviq> mzanetti, thing is we don't want to let the scopes decide
[10:58] <mhr3> mzanetti, why should it care? it's ui thing whether it want to launch something or preview it?
[10:58] <Saviq> mzanetti, apps are the exception
[10:58] <davmor2> mhr3: So do you need a fresh bug for this issue?
[10:59] <mhr3> davmor2, no duplication when you search?
[10:59] <davmor2> mhr3: duplication does indeed go when I search
[11:00] <mhr3> mzanetti, it's just that sometimes scopes will give you preview instead of directly launching it :)
[11:00] <mhr3> mzanetti, but if you do request a preview you will get a preview
[11:00] <mhr3> davmor2, can you search in the dash for "moves" and screenshot it?
[11:01] <mzanetti> so we're 100% sure that everything should always open a preview (except apps)
[11:01] <mzanetti> ?
[11:02] <mhr3> mzanetti, that's what design told us
[11:02] <mhr3> and that's what unity7 does now
[11:02] <mzanetti> mhm....
[11:02] <davmor2> mhr3: http://ubuntuone.com/5ke5YUabcgNHzf9RJo8ZLu
[11:02] <mzanetti> ok. in that case I'd say the activate() should never deliver a preview
[11:02] <mhr3> mzanetti, sorry, can't guarantee
[11:03] <mzanetti> but this seems all a mess then imho
[11:03] <mzanetti> if the scope has the power to device if it'll open a preview or not. then it also should tell us that
[11:03] <mzanetti> if unity is the one to decide than activate() should do what it says it does
[11:03] <mhr3> mzanetti, you can assume it doesn't, but unfortunately there are valid use-cases when an activation will bring up preview
[11:03] <mhr3> but those are rare
[11:04] <mzanetti> yeah... and exactly that's why I thought the if(name == applications) hack is bad
[11:04] <mzanetti> because there are more exceptions
[11:04] <mhr3> mzanetti, i agree, yet it's a ui exception, not a scope exception
[11:06] <mzanetti> mhr3: what are those use cases where activate() should bring a preview?
[11:06] <mhr3> davmor2, sorry, meant in the apps dash page
[11:06] <mhr3> mzanetti, things that need payment
[11:06] <mzanetti> mhr3: apps?
[11:07] <mhr3> anything that needs payment
[11:07] <mhr3> apps music videos
[11:07] <mhr3> you can't just "activate" those results
[11:07] <mzanetti> mhr3: assuming we would only call activate() on installed apps anyways
[11:07] <mzanetti> are there still installed apps that need to open a payment dialog before launching?
[11:08] <davmor2> mhr3: http://ubuntuone.com/0sge41sSr0oGMViZFRLeuy
[11:08] <mhr3> mzanetti, well right now we don't do payments anywhere in unity8
[11:09] <mzanetti> sure.. but in the future... it somehow seems paymant for apps can only happen int he suggested apps, not in the installed ones.
[11:09] <mzanetti> but I might be wrong... people want to charge for everything at times :D
[11:09] <mhr3> davmor2, ok one more pastebin then, do the libunity-tool with -q ""
[11:10] <mhr3> mzanetti, heh, pay per use apps? :)
[11:10] <mhr3> opening new business models... why not
[11:10] <mzanetti> I really hope not... but I'm sure iOS supports something like that already
[11:10] <mzanetti> anyways, in that case it probably should be an in-app payment mechanism anyways
[11:11] <mhr3> anyway, there are (rare) cases where you might get a preview when asking a scope to activate something
[11:11] <mhr3> i don't think it needs to be super polished right now, but it should support that
[11:12] <mhr3> ie, i know spinner is hard in that case, so let's forget about it
[11:12] <mzanetti> ok... I'll change it then... but I warned you. this is getting messy
[11:12] <davmor2> mhr3: just so I get this one right the libunity-tool command you asked be to run earlier yes not just libunity-tool -q ""
[11:13] <mhr3> davmor2, yes, same as before but instead of -q moves do -q ""
[11:14] <davmor2> mhr3: http://paste.ubuntu.com/6149619
[11:15] <mhr3> davmor2, libunity-tool -s /usr/share/unity/scopes/applications.scope -q "" -r
[11:15] <mhr3> that one pls ^
[11:15] <davmor2> meh yeah sorry wrong paste
[11:16] <davmor2> mhr3: http://paste.ubuntu.com/6149634
[11:17] <davmor2> mhr3: I forgot to hit copy after select all D'oh. it's been a long day and I only started at 11 :D
[11:20] <mhr3> davmor2, eh, one more pls, libunity-tool -s /usr/share/unity/scopes/home.scope -q "" -r
[11:21] <Saviq> pstolowski, mhr3 re: bug #1226514 - how does that work in unity7?
[11:21] <mhr3> Saviq, yes
[11:22] <mhr3> Saviq, mzanetti, clicking a preview button can send back a "new" preview, in this case with updated button
[11:23] <mzanetti> creating a whole new preview?
[11:23] <davmor2> mhr3: http://paste.ubuntu.com/6149656
[11:24] <mhr3> davmor2, hm, something is broken there, once again pls
[11:25] <mhr3> i mean, until it's different :)
[11:26] <davmor2> mhr3: http://paste.ubuntu.com/6149661  that is different
[11:26] <pstolowski> mzanetti: yes
[11:27] <mzanetti> i see... on installing click apps for example
[11:27] <mhr3> davmor2, you installed those via the software center?
[11:27] <davmor2> mhr3: I did
[11:27] <mhr3> davmor2, did they fly into the launcher when you did?
[11:27] <mhr3> trevinho, you broke stuff ^
[11:27] <davmor2> mhr3: they did
[11:27] <mhr3> davmor2, did you unpin them after they did?
[11:27] <mzanetti> pstolowski: what happens if I install a click app, and while the progress bar fills in I request another preview? will the update to the other be cancelled?
[11:28] <Saviq> mhr3, well, yeah - it doesn't in unity8, but works in unity7?
[11:28] <mhr3> Saviq, right, sorry missed the "how" the first time :)
[11:28] <davmor2> mhr3: I did otherwise I have an unusable launcher there are 960 apps to test
[11:28] <mhr3> davmor2, perfect, can you note those things in a bug report pls?
[11:28] <davmor2> mhr3: sure
[11:28] <Saviq> mzanetti, not entirely sure how it works right now, but the idea was that "progress" would be an action that would get triggered on complete
[11:29] <davmor2> mhr3: is it just against unity7 or something specific
[11:29] <mhr3> davmor2, yes, unity7
[11:29] <Saviq> mzanetti, so if we moved away from that preview, we should stop it from sending any actions, but refresh when we go back
[11:29] <davmor2> no worries
[11:29] <mzanetti> Saviq: I mean, once the progress bar reaches 100%, the preview changes to have 3 buttons instead of a progressbar
[11:30] <mhr3> davmor2, also, it'll remain broken for you even after it's fixed, sorry :/
[11:30] <mzanetti> Saviq: and from what I understood that happens with the same signal as a new preview would have been requested
[11:30] <Saviq> mzanetti, yeah, that *should* be handled by the fact that reaching 100% triggers that action, and the scope comes back with a new preview
[11:31] <mzanetti> yeah... comes back with a new preview. what if the user switched over to another preview? that will be overridden with the old, completed one
[11:31] <Saviq> mzanetti, that action shouldn't be triggered
[11:31] <davmor2> mhr3: that's not a biggie I just didn't want it broken for end users,  I'll be wiping my system and reinstalling once I get all the app installed hitting 900+ ppas in apt-get update takes several hours :D
[11:32] <Saviq> mzanetti, unless you're thinking the action was already triggered, and we're just waiting for a response...
[11:34] <mhr3> mzanetti, trigerring the preview progress is same as triggering any other preview button - they can return a new(/updated) preview and navigating away should cancel those requests
[11:34] <mzanetti> mhm...
[11:34] <mhr3> mzanetti, pstolowski has a branch that does preview cancellation
[11:35] <mhr3> well, in the backend... might need some extra hooking up
[11:39] <pstolowski> mhr3, mzanetti : yep.. and I just realized I don't have cancellations for preview actions. and interestingly, unitycore doesn't seem to support that :/
[11:39] <davmor2> mhr3: bug #1229681
[11:40] <davmor2> mhr3: did you want any of the pastebins adding or are the steps to reproduce enough
[11:42] <mzanetti> pstolowski, Saviq: ok... I pushed to the branch. should hopefully do what it is expected to: https://code.launchpad.net/~mzanetti/unity8/switching-previews/+merge/186991
[11:43] <mzanetti> as in only call preview except for installed apps (which triggers the activityindicator also onClick)
[11:44] <Saviq> mzanetti, runningApps are handled separately, right?
[11:44] <mzanetti> Saviq: seems so, yes. not triggering any of this code
[11:44] <Saviq> mzanetti, k
[11:45] <Saviq> mzanetti, you actively disabling swiping in the list of screenshots when there's no overflow?
[11:46] <mzanetti> Saviq: yes
[11:46] <Saviq> mzanetti, not sure we want that
[11:46] <mzanetti> can drop it... felt right to me
[11:47] <Saviq> mzanetti, can you get design folk to look at the whole thing?
[11:47] <mzanetti> yeah, on it
[11:49] <Saviq> mzanetti, right, so... if you switch between previews while they're loading, they get mixed up
[11:50] <Saviq> mzanetti, same with the update you mentioned
[11:50] <Cimi> mzanetti, is there a way to slow down autopilot moves?
[11:51] <mhr3> davmor2, that's ok, i added a comment
[11:51] <mzanetti> Saviq: yeah... pstolowski is still working on the cancellation branch
[11:51] <Cimi> it's super fast I cannot see why it's failing
[11:51] <Saviq> mzanetti, right, that will help things
[11:52] <mzanetti> Cimi: not entireley sure how. I think dandrader changed it intentionally to jump instead of move
[11:52]  * dandrader reads backlog
[11:52] <davmor2> mhr3: nice one, /me goes off to break something else now
[11:53] <Cimi> or if someone wants to help me here..
[11:54] <mhr3> mzanetti, suppose you should merge it with pstolowski's branch then
[11:54] <dandrader> Cimi, mzanetti , well, I don't recall anything about this s/move/jump story...
[11:54] <Cimi> ~cimi/unity8/unity8.hud-2_hint-reveal-commit/
[11:54] <Cimi> hud tests are failing...
[11:57] <Cimi> unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears
[11:57] <Cimi> is failing
[12:02] <mzanetti> Saviq: merged it with pstolowski's branch. looks quite good now.
[12:02] <Saviq> mzanetti, great
[12:02] <mzanetti> pstolowski: any particular reason you didn't propose your branch for merging yet?
[12:08] <Saviq> mzanetti, I wonder if we should block on activate() in the preview - so that you can't switch away from a preview you've executed an action on...
[12:09] <Saviq> mzanetti, or somehow match the preview coming back with the spot where it should show up...
[12:10] <kgunn_> Saviq, so did you have any idea which osk issue olli was referring to ?
[12:10] <mzanetti> Saviq: wait... so. for example I trigger install on a recommended app
[12:10] <Saviq> kgunn_, no
[12:10] <Saviq> mzanetti, yeah, and switch away
[12:11] <mzanetti> Saviq: the progress bar starts. ok. switching away while waiting to be installed
[12:11] <Saviq> mzanetti, I'm not sure that actually works as intended atm
[12:12] <Saviq> mzanetti, I think the preview does the switching internally - except when there's an error, for example
[12:12] <mzanetti> I'm afraid it doesn't.... I guess the biggest problem is that items can disappear from the model while the previews are open
[12:12] <mzanetti> well... actually... not really
[12:12] <Saviq> mzanetti, well, they could in theory, but we can make sure they won't
[12:12] <Saviq> mzanetti, i.e. it's us that control when search results are refreshed
[12:13] <Saviq> kgunn_, all of the things you mentioned in your emails are out of our control
[12:13] <mzanetti> Saviq: us as in the ui?
[12:13] <Saviq> mzanetti, yes
[12:13] <Saviq> mzanetti, with https://code.launchpad.net/~unity-team/unity8/scope-isactive/+merge/187179
[12:14] <mzanetti> Saviq: ok... so I switch away, item gets destroyed. I switch back and the preview gets requested again
[12:14] <mzanetti> Saviq: should be fine I'd say
[12:14] <Saviq> mzanetti, it's not that
[12:14] <Saviq> mzanetti, and it doesn't get destroyed - not straight away - only when you switch more than one item away
[12:15] <mzanetti> yeah... that's true. that can be fixed tho
[12:15] <Saviq> mzanetti, cacheBuffer should be 0 btw
[12:15] <Saviq> mzanetti, still
[12:15] <Saviq> mzanetti, if you activate an action in preview 1
[12:15] <Saviq> mzanetti, and switch to preview 2
[12:15] <Saviq> mzanetti, right now the response for preview 1 will come to preview 2's spot
[12:16] <mzanetti> Saviq: that's what I asked before... pstolowski said it will be cancelled
[12:16] <mzanetti> Saviq: as soon as we trigger a new preview() request, any actions won't trigger the update any more
[12:16] <Saviq> mzanetti, ok, let's see
[12:17] <ChrisTownsend> seb128: didrocks: ping
[12:17]  * mzanetti setting cacheBuffer to 0
[12:17] <Saviq> mzanetti, what if you close the preview after having activated?
[12:17] <seb128> ChrisTownsend, hey
[12:17] <mzanetti> Saviq: hmm... that might be an issue indeed.
[12:18] <ChrisTownsend> seb128: Hey, I have a Unity/distro related question for you.
[12:18] <ChrisTownsend> seb128: Does Distro agree with this MP: https://code.launchpad.net/~jbicha/unity/recommend-telepathy-indicator/+merge/186392
[12:18] <mzanetti> Saviq: but tbh... I think its quite a bad idea that everything can ship a preview at any time and we have no clue where it came from and what it is
[12:19] <seb128> ChrisTownsend, that seems fine to me yes
[12:19] <ChrisTownsend> seb128: Ok, thanks, then we'll approve it.
[12:19] <seb128> ChrisTownsend, thanks
[12:20] <seb128> ChrisTownsend, since you are online, jibel and dholbach were looking for you earlier, new compiz seems to have lag issues on intel (your name come next to most of the approved changes in the recent landing so I guess it's a problem for you)
[12:21] <ChrisTownsend> seb128: Uhh...
[12:21] <Saviq> mzanetti, yeah, I agree I'm not liking that cat'n'mouse play
[12:21] <mzanetti> Saviq: it should be a proper model, holding all items and data for all the stuff (initially empty). with a fetch(index) to actually fill in the data if remote content
[12:21] <ChrisTownsend> seb128: Hardly anything went into Compiz in the last release, definitely nothing that would affect performance.
[12:22] <mzanetti> Saviq: that way specific data can be updated in a performant and predictable manner, instead of just overwriting the whole set of data of whatever the current page is
[12:22] <Saviq> mzanetti, problem is you can't know what type of preview you'll get
[12:22] <mzanetti> Saviq: withing a category it should be always the same, no?
[12:23] <Saviq> mzanetti, not necessarily
[12:23] <kgunn_> Saviq i don't disagree with you
[12:23] <Saviq> mzanetti, a request for a preview for the same item might get you different preview type, depending on other conditions
[12:23] <kgunn_> just need to convince the our bosses :)
[12:23] <seb128> ChrisTownsend, ok, maybe that one is unity ... there was also the compiz/multiple workspace/focus issue that seems to be fixed in trunk
[12:23] <seb128> ChrisTownsend, http://irclogs.ubuntu.com/2013/09/24/%23ubuntu-unity.html#t09:15
[12:24] <ChrisTownsend> seb128: Yes, the workspace issue, I'm very familiar with:-(
[12:24] <mzanetti> Saviq: then we'd need a "previewType" property in the model data.
[12:24] <mzanetti> Saviq: that can change at any time
[12:24] <ChrisTownsend> seb128: That is definitely fixed, but that should have zero performance impact.
[12:25] <seb128> ChrisTownsend, ok, maybe the performance stuff is another bug
[12:25] <ChrisTownsend> seb128: Well, I have an Intel machine have not noticed any subpar performance.
[12:25] <seb128> jibel, ^ did you open a bug about the performance thing?
[12:25] <Saviq> mzanetti, potentially, yes, we'd have to go through all of the use cases and see where we can go - but anyway, not this time
[12:26] <mzanetti> Saviq: yes. I agree... something for a cold december day :D
[12:26] <ChrisTownsend> seb128: Also, new Firefox and Tbird was released recently.
[12:26] <seb128> ChrisTownsend, right, that could be an issue with those apps if that's specific to them
[12:27] <ChrisTownsend> seb128: Ok, that seemed to be all that was mentioned.
[12:28] <ChrisTownsend> seb128: I doubt they have Atom based machines, but performance on those chips is pretty bad right now.
[12:28] <ChrisTownsend> seb128: Due to Mesa 9.2
[12:29] <ChrisTownsend> seb128: Anyways, I can only speculate right now, so I'll keep a look out for any poor performance related bugs.  Thanks!
[12:30] <seb128> ChrisTownsend, thanks ;-)
[12:31] <jibel> seb128, no I didn't, the machine I tested on is a test machine that I don't use every day, and I don't have a good base for comparison. I'll ask dholbach to submit one as he seems most affected by this performance issue
[12:32] <seb128> jibel, thanks
[12:41] <pstolowski> mzanetti: only reason it's not MPed is because I was adding support for result row to it
[12:42] <mzanetti> pstolowski: ah ok... no worries then. I've merged the current state into my branch and set it as a prerequisite branch
[12:43] <mzanetti> pstolowski: seems to work quite well btw
[12:43] <mzanetti> pstolowski: one thing I'd need is to manually cancel stuff
[12:44] <mzanetti> pstolowski: assuming I open the preview for a click app, click in install, then close the preview. when the installation is completed I think it would open again because of the action stuff
[12:45] <kgunn_> MacSlow|lunch, when will the mp be for prompting pin dialog ?
[12:47] <pstolowski> mzanetti: hmm, why? I'm giving you a preview instance, and make QML the owner of it, so it will be gone?
[12:47] <mzanetti> pstolowski: didn't you guys tell me before that in that case new preview will be generated?
[12:48] <mzanetti> if that's not the case then we're fine
[12:51] <pstolowski> mzanetti: you mean this: mhr3 | mzanetti, trigerring the preview progress is same as triggering any other preview button - they can return a new(/updated) preview and navigating away should cancel those requests"? I'm not sure tbh
[12:51] <mzanetti> pstolowski: yeah... that one
[12:57] <mhr3> pstolowski, mzanetti, you know in the ui when a preview is closed, at that point you should call something so that any pending requests to the scope (like waiting for response to action-activated) can be cancelled
[12:57] <mhr3> something == something that you'll agree on with pstolowski :)
[12:58] <mzanetti> mhr3: yeah... that's what I asked pstolowski for :)
[12:58] <mhr3> right, i'm just translating ;P
[12:58] <pstolowski> mzanetti, mhr3 : ok, got you.. will add that, though afaict we miss that bit on unity core side...
[12:59] <mhr3> pstolowski, we do? don't we pass cancellable to those?
[12:59] <pstolowski> mhr3: not to action activation in Preview::performAction()
[13:00] <mhr3> pstolowski, :/ we need to fix unity-core then
[13:00] <mhr3> i hate touching unity-core, the whole thing is an abi break waiting to happen
[13:01] <MacSlow> kgunn_, as soon as I solved the exported MenuModel not showing up in the AP-tests... currently don't know what's causing this.
[13:02] <kgunn_> MacSlow, so does it work on the phone? i'm assuming you see the unexpected on the pc ?
[13:05] <MacSlow> kgunn_, yes... the issue is on the desktop-machine... I've not yet tried the ap-test on the phone yet.
[13:05] <kgunn_> greyback, thanks for the top approval help
[13:06] <greyback> kgunn_: only did my bit, hope everythings ok
[13:06] <kgunn_> MacSlow, it'd be interesting to see not only the AP test on the phone...but even just manual use case exercise
[13:07] <MacSlow> kgunn_, I can verify that today
[13:07] <Saviq> olli_, around?
[13:08] <olli_> Saviq, yep
[13:11] <kgunn_> MacSlow, thanks...one more ques, is the back end there & ui tied in?
[13:14] <MacSlow> kgunn_, yes... for the MP only the autopilot-tests are missing (for pinunlock, password and user-auth) ... wifi-selection still has to be completed
[13:15] <kgunn_> MacSlow, oh yeah...i knew about wifi...but sim pin is the one we're gunning for
[13:16] <kgunn_> good to hear its all tied in
[13:16] <MacSlow> kgunn_, I was told by dednick, that the way signal-strength needs to be passed in a different way.
[13:16] <MacSlow> kgunn_, I think I already showed off the first three dialog-cases in screencasts already.
[13:17] <kgunn_> MacSlow, yeah...but can't tell if backend is there (at least i can't)
[13:18] <dednick> tedg: might be a good time for a full review of the simlock indicator-network branch of mine.
[13:27] <karni> mhr3: Hey man, would you have a sec to chat about what we last talked on g+? I need to access a model backing a scope. While I can iterate over items, CategoryResults type seems unmutable, and you can't instantiate CategoryResults from QML. Any ideas how I could update a model backing a scope?
[13:28] <karni> mhr3: Unless I can remove an item from a music (sub)scope, we can't integrate the OneAPI billing demo with the real music scope.
[13:28] <tedg> dednick, Ah, okay.  Is the notification support in Unity trunk or do I need a branch?
[13:29] <mhr3> karni, pls rewind, why do you need to change that model?
[13:31] <dednick> tedg: you'll need some branches
[13:31] <hallyn> is there any plan to add some sort of "project window grouping"?  (so i can minimize/restore/switch between groups)
[13:32] <dednick> tedg: lp:~nick-dedekind/unity-notifications/simunlock.dialog
[13:32] <dednick> tedg: lp:~nick-dedekind/unity8/simunlock.dialog
[13:35] <dednick> Saviq: standup?
[13:36] <Saviq> dednick, indeed
[13:37] <greyback> Saviq: I'm doing the notes
[13:37] <Saviq> greyback, yeah I see
[13:38] <pstolowski> mzanetti: I've updated my cancellation branch. i'm leaning towards MPing it and handling action cancellation separately (since it needs a change in unitycore, and this will delay entire thing)
[13:40] <mzanetti> pstolowski: fine with me
[13:48] <mzanetti> Cimi: so what exactly is the issue?
[13:48] <Cimi> mzanetti, failing tests? :)
[13:48] <Cimi> on the hud
[13:48] <mzanetti> where?
[13:48] <Cimi> maybe it's math
[13:48] <Cimi> mm doesn't seem like math
[13:49] <Cimi> it's weird
[13:50] <mzanetti> Cimi: where is this happening=
[13:50] <mzanetti> ?
[13:50] <Cimi> hud
	 ~cimi/unity8/unity8.hud-2_hint-reveal-commit/
[13:50] <Cimi> 12:54 | <Cimi>	 hud tests are failing...
[13:50] <Cimi> 12:57 | <Cimi>	 unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears
[13:54] <tedg> greyback, Hey, are you planning on landing the upstart support for start/stop in a separate branch from focus/resume ?
[13:54] <tedg> greyback, Or is that all one mega-upstart-app-launch branch?
[13:54] <greyback> tedg: upstart will be one branch
[13:55] <greyback> separate branch for focus/resume
[13:56] <tedg> greyback, Okay, makes sense.
[13:56] <tedg> greyback, So I'm not blocking the first one without the focus/resume stuff today, but probably soon.
[13:56] <tedg> greyback, When will I block you?  :-)
[13:57] <greyback> tedg: nope, you're not blocking me on the upstart stuff. That's me being slow getting tests working around it.
[13:58] <greyback> tedg: I don't think you will. From the mails you'll have the focus/resume stuff done pretty soon
[13:58] <tedg> greyback, Yeah, I'm hoping today.  But more worried about landing, releasing, etc.
[13:59] <tedg> greyback, But wanted to make sure that wasn't an issue, so we could find a solution if it was.  (i.e. release the API without backing or something)
[14:01] <greyback> tedg: you can land and release your stuff independently of my work - just tell me when so I can increment my package dependencies.
[14:01] <mzanetti> Cimi: but what's the issue? I mean, you changed the behavior. of course tests are going to fail. You need to update them
[14:02] <tedg> greyback, Sure, but you can't link to symbols that don't exist.  So I need to get my part done first :-)
[14:03] <greyback> tedg: indeed. But I can manage locally with your proposed focus/resume API until you've that part ready
[14:03] <mzanetti> Cimi: it doesn't seem that complex after all
[14:03] <Cimi> mzanetti, can we slow down the mouse?
[14:03] <greyback> tedg: so don't worry about me, I'm too far behind you just yet
[14:03] <mzanetti> Cimi: no... but I don't think you need that
[14:03] <Cimi> mzanetti, code seems correct to me
[14:03] <mzanetti> Cimi: well, you can. but I don't know how out of the top of my head
[14:04] <mzanetti> Cimi: so. start with one test only. run this: autopilot run unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears
[14:05] <mzanetti> Cimi: the test will fail, telling you that the buttons opacity is not 1.0 as expected by the test in line 61
[14:05] <mzanetti> Cimi: but instead it is 0.5
[14:05] <mzanetti> which is what you have changed. so adjust the expected value to 0.5
[14:05] <mzanetti> no?
[14:05] <Cimi> should be 1
[14:07] <mzanetti> Cimi: right... the swipe_coords don't seem to match any more
[14:07] <Cimi> mzanetti, mmm maybe because of the bottomMargin
[14:08] <Cimi> nope
[14:08] <Cimi> doesn't make sense
[14:08] <mzanetti> Cimi: I added a sleep(10) before that check
[14:08] <mzanetti> Cimi: it seems to move the pointer only very little
[14:09] <mzanetti> Cimi: because it moves it to hud_show_button.y - hud_show_button.height
[14:09] <mzanetti> Cimi: did you change the height of the button item?
[14:10] <Cimi> nope
[14:23] <pstolowski> mzanetti: my MP https://code.launchpad.net/~stolowski/unity8/cancel-previews/+merge/187249
[14:44] <mzanetti> Cimi: so actually the issue seems to be that the button doesn't change its opacity to 1 indeed
[14:44] <Cimi> mzanetti, yep but why?
[14:46] <mzanetti> Cimi: I have a feeling... let me verify.. will take 5 mins or so
[14:46] <Cimi> mzanetti, could be that onDistanceChanged is not emitted
[14:50] <mzanetti> Cimi: I think its the usage of Behavior together with states... thats a bad thing... but there is another issue
[14:50] <mzanetti> Cimi: right now I see the button has 4 opacity values
[14:51] <mzanetti> Cimi: 0 (when its hidden)
[14:51] <mzanetti> Cimi: then there is one that looks like 0.25 (during the time it moves up/down)
[14:51] <mzanetti> Cimi: 0.5 when it reached its final place but does not contain the mouse
[14:51] <mzanetti> Cimi: and 1 when it contains the mouse
[14:51] <mzanetti> Cimi: hoewer, I can find only 3 of them in the code
[14:52] <Cimi> mzanetti, those are internal
[14:52] <Cimi> mzanetti, hudButton changes the real opacity
[14:52] <mzanetti> Cimi: yeah... I'm looking at the code. not the test
[14:52] <Cimi> mzanetti, but from outside (what we are testing, bottomBar), it's correctly either 0.5 or 1
[14:52] <mzanetti> as I believe the issue is actually there
[14:53] <mzanetti> Cimi: why doesn't hint have a opacity value set?
[14:54] <mzanetti> the state "hint"
[14:54] <mzanetti> so I'm quite sure thats the isse. if there is a state change while the behavior is still running the behavior overwrites the target state value again
[14:54] <mzanetti> Cimi: 1) make sure all states have opacity values defined
[14:54] <Cimi> mzanetti, it does 0.5
[14:55] <Cimi> mzanetti, line 215 here
[14:55] <mzanetti> Cimi: 2) use a transition instead of behavior
[14:55] <mzanetti> Cimi: sorry... meant the state "reveal"
[14:55] <mzanetti> oh... it has extends hint
[14:55] <Cimi> yep
[15:01] <Cimi> mzanetti, it works with the mouse though...
[15:05] <mzanetti> this is really weird stuff indeed
[15:07] <Cimi> mzanetti, might be onDistance
[15:08] <mzanetti> mhm... that looks suspicious indeed
[15:09] <mzanetti> Cimi: yeah... quite sure thats it
[15:10] <mzanetti> Cimi: the question is why though
[15:11] <mzanetti> dandrader: can you see why this failes with autopilot? http://paste.kde.org/p7e10ed32
[15:11] <mzanetti> Cimi: hah... probably it doesn't even go to recognized
[15:12] <mzanetti> because the autopilot moves so fast that it's not detected to be a valid gesture
[15:12] <Cimi> mzanetti, yeah
[15:12] <Cimi> mzanetti, I was thinking that too
[15:12] <dandrader> mzanetti, maybe autopilot is simulating a drag with move events too far apart
[15:13] <mzanetti> dandrader: yeah... I think at some point they changed it to only do 2 points. start and end
[15:14] <dandrader> mzanetti, so it's going straight to commitDistance, skipping the step where it would hit the revealDistance check
[15:15] <dandrader> mzanetti, well, if I'm not mistaken, I recall I solved at least two autopilot issues I had by adding more steps into autopilot's drags
[15:16] <mzanetti> Cimi:^^
[15:16] <Cimi> mzanetti, but it's not solved now :)
[15:17] <mzanetti> ?
[15:17] <mzanetti> Cimi: did you try what daniel suggested?
[15:18] <Cimi> mzanetti, of course not
[15:24] <Cimi> dandrader, adding those steps where? in the test case?
[15:39] <mzanetti> Cimi: yeah... in the testcase... but for some reason I can't make it work
[15:39] <mzanetti> gosh I hate autopilot
[15:47] <mzanetti> Cimi: ok. one step closer
[15:47] <mzanetti> Cimi: this is the debug print from onDistanceChanged
[15:48] <mzanetti> DDA status: 0
[15:48] <mzanetti> DDA status: 1
[15:48] <mzanetti> DDA status: 2
[15:49] <mzanetti> so it looks the dda is not the issue after all
[15:56] <Saviq> fginther, ah, you beat me to it by a minute, have now cancelled my duplicate job in unity8-ci
[15:56] <Saviq> fginther, I must say we've much improved on the stability of our tests now...
[15:57] <fginther> Saviq, glad to hear that.
[15:57] <Saviq> fginther, although I'm still seeing quite a bit of https://code.launchpad.net/~unity-team/unity8/scope-isactive/+merge/187179/comments/427167
[15:57] <Saviq> fginther, where all the tests on mediumtests-touch fail
[15:57] <Saviq> (ignore qmluitests, that's valid failure)
[15:58] <Saviq> fginther, I wonder if the 10s timeout is not enough there
[15:59] <mzanetti> Cimi: ok... there is something more weird
[16:00] <mzanetti> Cimi: I added debug prints in that onDistanceChanged and it turns out, the opacity is not related to the states at all
[16:00] <mzanetti> Cimi: seems you overwrite it somewhere
[16:00] <Saviq> fginther, what's the issue with the runner for multiple suites? if it can be compressed to a sentence or two :)
[16:00] <mzanetti> Cimi: when the state goes to shown the opacity is still 0.5. then only when it has onmouseover it goes to opacity 1. still staying in the shown state
[16:01] <mzanetti> Cimi: I'd suggest you clean that mess up a bit... for example you add Behavior on opacity twice, once in BottomBar and once in HudButton etc...
[16:01] <mzanetti> Cimi: hopefully it'll be easier to debug afterwards. or might even work magically
[16:02] <mhr3> mzanetti, i think your preview branch makes the music grid behave differently than the rest of them?
[16:02] <mhr3> would be nice to fix :)
[16:02]  * mzanetti checks
[16:03] <fginther> Saviq, my theory is that we need a reboot between the two test suites. unity8 has special handling to restart the shell and possibly that is causing the app tests to fail
[16:04] <Saviq> fginther, well, it should work without reboots, so let's make sure it does somewhen soon
[16:04] <Saviq> fginther, we should be able to repro locally with otto ,right?
[16:04] <fginther> Saviq, otto still needs some work for touch
[16:05] <fginther> Saviq, we've been using om26er's scripts so far
[16:05] <Saviq> fginther, so phablet-test-run?
[16:05] <fginther> Saviq, checking
[16:07] <fginther> Saviq, it's calling autopilot directly, it should be updated to use phablet-test-run
[16:09] <Saviq> fginther, ok, I'll try and reproduce our latest failures tomorrow
[16:09] <Saviq> fginther, it might be as easy as adding some delay
[16:11] <Saviq> mzanetti, btw, there's a conflict in your split surfaces branch, when you have some free cycles (sic!)
[16:14] <mzanetti> Saviq: are you using that branch for something?
[16:14] <Saviq> mzanetti, trying to run it on mir currently
[16:14] <mzanetti> ahok
[16:14] <Saviq> mzanetti, I solved the conflict here, but there's some weirdness in launcher height
[16:15] <Saviq> mzanetti, so might be I did something wrong
[16:15]  * mzanetti merges while waiting for compile run on phone
[16:16]  * Saviq just set up sbuild+ccache properly on manta, hopes to speed up ↑
[16:16] <Saviq> mzanetti, can get you a script for ↑ that does *almost* everything needed
[16:16] <mzanetti> won't that break every time you flash?
[16:17] <Saviq> mzanetti, somewhat
[16:17] <Saviq> mzanetti, I'm bind-mounting everything to /home/phablet
[16:18] <Saviq> mzanetti, or almost everything
[16:18] <Saviq> mzanetti, so it should be a case of `apt-get install sbuild` on flash, assuming home is preserved, which was not the case for me a few times now
[16:18] <Saviq> mzanetti, but well, who needs flashing anyway, apt should be good enough for a build machine ;)
[16:19] <mzanetti> Saviq: well... I flashed countless times in the last 2 days for some reason :D
[16:20] <Saviq> mzanetti, CRAZY!
[16:20] <mzanetti> Saviq: you know why
[16:20] <Saviq> mzanetti, yeah, /me still needs to try and repro with the latest stuff
[16:20] <Saviq> that's one of the reasons why I have the sbuild, so that I can build latest trunks and beat the heck out of it on the devices
[16:21] <mzanetti> Saviq: nah... I'm pretty sure what happened and pawel's fixes look really good
[16:38] <MacSlow> Saviq, any idea by chance what changed in the current touch-image that could cause gi/DBus/Python to no longer work... -> http://pastebin.ubuntu.com/6150866
[16:39] <Saviq> MacSlow, what if you run it manually?
[16:39] <Saviq> MacSlow, the dbus-launch... command, I mean?
[16:39] <MacSlow> Saviq, oh... btw... I'm using the flash-target "ubuntu-system" as "cdimage-touch" didn't work on my GalaxyNexus...
[16:39] <Saviq> MacSlow, it exited with code 1, so it sounds like an error dbus-launch removed
[16:39] <MacSlow> oh one sec
[16:40] <Saviq> s/removed/returned/
[16:40] <Saviq> MacSlow, image shouldn't matter
[16:40] <MacSlow> Saviq, doh... -> "Autolaunch error: X11 initialization failed."
[16:42] <Saviq> MacSlow, sounds like something in your env is b0rked
[16:42] <Cimi> mzanetti, I didn't add it :)
[16:42] <MacSlow> Saviq, I hardly touched the settings after I flashed it
[16:43] <mzanetti> Cimi: not really sure how to answer that one :D
[16:43] <Cimi> mzanetti, I just added a couple of states… you can see from the diff
[16:43] <MacSlow> Saviq, never mind... wasn't id=phablet...
[16:43] <Saviq> MacSlow, not sure what to make of that, no idea how dbus-launch should behave... or what it requires...
[16:43] <MacSlow> Saviq, works now
[16:43] <Saviq> MacSlow, right
[16:44] <MacSlow> Saviq, still not fully back yet...
[16:44] <Saviq> MacSlow, fish are EVIL
[16:45] <MacSlow> Saviq, well... I tried a new sushi-place downtown...
[16:45] <mzanetti> muahaha
[16:45] <MacSlow> Saviq, looked very fancy and good...
[16:46] <mzanetti> if you really need to have fish... at least cook it before dude
[16:46] <mzanetti> :P
[16:46] <MacSlow> but then, I didn't see their shopping-habits or kitchen, which one usually takes for granted to be ok
[16:46] <Cimi> mzanetti, are you sure of this opacity thing?
[16:46] <Cimi> mzanetti, from what I see, there are two opacity
[16:46] <MacSlow> mzanetti, I'll stick to the known sushi-bars in the future
[16:47] <MacSlow> Saviq, password and user-auth dialogs work...
[16:47] <Cimi> mzanetti, one is in bottom bar, and one in hudbutton
[16:47] <Cimi> mzanetti, we are checking the one in bottom bar
[16:47] <Saviq> MacSlow, cool
[16:47] <MacSlow> Saviq, simunlock doesn't... as the indicator-network is "in the way"
[16:47] <Saviq> MacSlow, sure, MP away!
[16:47] <mzanetti> Cimi: yeah... the state "shown" has different opacity values, depending on the position of the mouse
[16:47] <mzanetti> Cimi: while it should only have the one defined in that state
[16:48] <Cimi> mzanetti, it only has one
[16:48] <Cimi> mzanetti, 1.0
[16:48] <Saviq> mzanetti, yay, we got two surfaces on Mir - only problem you can only see the "flickers" from the launcher one ;)
[16:48] <mzanetti> Cimi: yeah... in the code... but not for real
[16:48] <MacSlow> Saviq, the ap-tests aren't done/working yet... and I now have to sort out how to make the simunlock work with "indicator-network" being running in the bg
[16:48] <Saviq> mzanetti, but I assume this can be fixed by surface type or something
[16:48] <mzanetti> Cimi: add a onStateChanged hanlder wnd print the current state
[16:48] <Cimi> mzanetti, what you see is the internal opacity of hudbutton, doesn't count
[16:48] <Saviq> MacSlow, just so you know, tests are needed, but the feature probably even more
[16:49] <Saviq> MacSlow, so park the work on tests if you can, and let's just get the feature in and look at tests when it's done
[16:49] <mzanetti> Cimi: yes it counts... it makes the code unreadable and unmaintainable. and tests are so hard to debug that you can't do it yourself any more
[16:49] <MacSlow> Saviq, well at least let me try to sort out the now failing simunlock as kgunn (and pete-woods probably too) is urging to have it in image
[16:50] <Saviq> MacSlow, yup
[16:50] <mzanetti> Saviq: hmm... its a standard surface... shouldn't flicker
[16:50] <mzanetti> Saviq: the only exception is alwaysontop
[16:50] <mzanetti> Saviq: ah... might ba that the alwaysontop is not working so its actually behind
[16:50] <Saviq> mzanetti, yeah, but Mir probably doesn't handle everything, we need to set the surface type or something
[16:51] <mzanetti> Saviq: and you see it flicker because of the same reason you see apps shining trhough
[16:51] <Saviq> mzanetti, yup
[16:51]  * kgunn cheers on MacSlow 
[16:51]  * mzanetti too
[16:51]  * MacSlow wishes he was born a reno-air-race pilot atm
[16:51] <Saviq> \o\ /o/ \o/ \o\ /o/
[16:52] <mzanetti> can we change the channels topic?
[16:52]  * Saviq wonders who decided it's going to be cool to generate an ssh key per-ubuntu-device
[16:52]  * Saviq couldn't do password-login to some places and couldn't figure out why
[16:53] <Cimi> mzanetti, I don't think it changes anything in terms of tests
[16:53] <MacSlow> dednick, can the simunlock UI be used (in the snap-decision) with the indicator-network running?
[16:53] <Saviq> but it seems trying 6 keys in a row makes the other side say not nice things
[16:53] <Cimi> mzanetti, anyway, we can rewrite the code another time...
[16:53] <Cimi> mzanetti, I didn't write this
[16:53] <MacSlow> dednick, that's what's currently blocking it to work on the device
[16:53] <Saviq> MacSlow, doesn't the network indicator trigger the sim dialog?
[16:54] <mzanetti> Cimi: thing is debugged this for 2 hours now. I'm at the stage where I would start cleaning up the code if this would be my branch
[16:54] <dednick> MacSlow: I had it working on the device using my branches
[16:54] <Cimi> mzanetti, ok...
[16:54] <Cimi> mzanetti, I can start a rewrite but I cannot see how it could change
[16:54] <MacSlow> Saviq, well in the end yes... I guess... not sure about that integration-detail... but for demonstrating/testing I'd like to stick to my stand-alone python-examples... as I know much better how to control them
[16:54] <dednick> MacSlow: to a somewhat limited extent. I had some issues with ofono bugs. which are in progress
[16:55] <mzanetti> Cimi: not saying you should rewrite
[16:55] <mzanetti> but there is something fishy with the states
[16:55] <Cimi> mzanetti, I think it's only due to autopilot
[16:55] <Cimi> mzanetti, what's wrong with the states?
[16:55] <MacSlow> Saviq, dednick: hm... that leaves me in an akward position for the MR
[16:55] <dednick> MacSlow: why?
[16:56] <Cimi> mzanetti, I think the issue is that the mouse movement is not recognised
[16:56] <MacSlow> dednick, the example/test for the simunlock will never work on the device as is
[16:56] <mzanetti> Cimi: it is... I added debug prints for that
[16:56] <mzanetti> the state goes to shown
[16:56] <dednick> MacSlow: why not?
[16:57] <Cimi> mzanetti, and then?
[16:57] <mzanetti> Cimi: still the opacity goes not to 1, even if the state is "shown"
[16:57] <Cimi> why on earth?
[16:57] <MacSlow> dednick, doh... never mind... just fixed it
[16:58] <MacSlow> kgunn: you'll get you screencast in a few minutes...
[16:58] <Cimi> mzanetti, nothing is overriding opacity
[16:58] <mzanetti>  let me run it again
[16:59] <MacSlow> kgunn, Saviq, dednick, pete-woods: I'll do a MR for the three first ext. snap-decision dialogs then afterwards
[16:59] <pete-woods> :D
[16:59] <MacSlow> Saviq, I'll try to catch veebers later this night about my issues with ap-tests for the ext. snap-decisions, thus I can bring them in a later MR once I hopefully got them working
[17:05] <Cimi> mzanetti, still same issue?
[17:05] <Cimi> mzanetti, would be interesting doing the same with the mouse and see
[17:06] <mzanetti> Cimi: no... I was wrong about the state... this is the output when running the test: http://paste.kde.org/pa950fa89
[17:07] <Cimi> mzanetti, indeed it keeps stuck in hint
[17:07] <Cimi> mzanetti, can you bzr diff | pastebinit ?
[17:09] <mzanetti> Cimi: yeah. doing one more run with more debug prints. one sev
[17:09] <mzanetti> sec
[17:09] <Cimi> mzanetti, I have 10 mins then the gate closes and I'll lose my flight :)
[17:10] <mzanetti> Cimi: you're at the airport?
[17:10] <Cimi> mzanetti, yes
[17:10] <Cimi> mzanetti, in the lounge...
[17:10] <Cimi> mzanetti, gotta go to the dentist tomorrow afternoon :)
[17:11] <mzanetti> Cimi: http://paste.kde.org/pc78df946 and http://paste.kde.org/p4e152d15
[17:11] <Cimi> mzanetti, it's a relative
[17:11] <mzanetti> Cimi: you fly to your dentist... interesting
[17:11] <Cimi> lol
[17:12] <mzanetti> gotta renegotiate my salary I guess
[17:12] <mzanetti> :P
[17:12] <Cimi> mzanetti, what's interesting
[17:12] <mzanetti> just joking
[17:12] <Cimi> mzanetti, is that onDistanceChanged is emitted basically only once
[17:13] <Cimi> mzanetti, I mean one, very rarely
[17:13] <Cimi> mzanetti, it should print loads of them
[17:13] <Cimi> mzanetti, the drag is definitely too far
[17:13] <mzanetti> Cimi: yeah... autopilot does freaking begin/end steps aparently
[17:13] <mzanetti> but i even tried to do it in a loop
[17:13] <mzanetti> with calling each pixel manually
[17:14] <Cimi> mzanetti, we should add some function that splits the movements into more than one, using for
[17:14] <mzanetti> still nothing
[17:14] <mzanetti> lemme add it again
[17:14] <mzanetti> one sec
[17:14] <Cimi> too far -> too fast I meant
[17:14] <mzanetti> actually the too far was correct
[17:14] <Cimi> ok :)
[17:14] <mzanetti> but yeah... same thing somewhat
[17:15] <Cimi> mzanetti, the status "shown" is triggered by onDistanceChanged, same thing for the others
[17:15] <Cimi> mzanetti, so it kinda relies on that to work...
[17:17] <Cimi> mzanetti, unless the asserts kinda stop the swipe?
[17:19] <Cimi> I have to leave… I'll have a look when I land
[17:20] <Cimi> "at least I'll see the light"
[17:20] <mzanetti> Cimi: ok... I'll do some more debugging. by now I'm curious whats going on
[17:20] <mzanetti> have a good flight
[17:20] <Cimi> (aka, the sun)
[17:20] <Cimi> thanks
[17:20] <mzanetti> haha
[17:20] <Cimi> chat later
[17:20] <mzanetti> k
[18:03]  * greyback eod
[18:32] <MacSlow> kgunn, Saviq: screencast (still uploading) and MRs put up... see related eMail
[18:32] <Saviq> MacSlow, yeah, thanks!
[18:32] <kgunn> MacSlow: thanks man
[18:32] <Saviq> MacSlow, if you ask me, again, the feature is more important than the test
[18:32] <Saviq> MacSlow, so wifi selection dialog it is
[18:34] <MacSlow> Saviq, ok... also more likely to be completed before the week ends... regarding the ap-test... phew... I really don't know yet
[18:34] <Saviq> MacSlow, is ine
[18:34] <Saviq> fine
[18:34] <Saviq> we'll get there
[18:35] <MacSlow> think so too... see you folks tomorrow
[18:35] <Saviq> o/
[19:36] <Saviq> mterry, "Note: You can only anchor an item to siblings or a parent."
[19:36] <Saviq> mterry, at the end of http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#anchors.alignWhenCentered-prop
[19:36] <Saviq> mterry, and yeah, I saw it was working fine
[19:36] <Saviq> mterry, but let's just be correct for the sake of correctness :)
[19:37] <mterry> Saviq, maybe by "siblings or parents" they really mean "non-children"
[19:37] <Saviq> mterry, not "parents", but "a parent"
[19:38] <mterry> Saviq, correct, but my point is the same.  They may just be meaning "anywhere else in the widget tree is fine, just not below the anchor"
[19:38] <Saviq> mterry, http://paste.ubuntu.com/6151579/
[19:38] <Saviq> test.qml:11:9: QML Item: Cannot anchor to an item that isn't a parent or sibling.
[19:38] <Saviq> mterry, been there, done that
[19:39] <Saviq> mterry, your thing doesn't go up with that warning with sheer luck ;)
[19:39] <Saviq> mterry, I'd be keen to look if it actually is set through the createObject
[19:39] <mterry> Saviq, OK...  how does mine even work then?
[19:39] <Saviq> mterry, no idea ;)
[19:39] <Saviq> mterry, been looking through the log to see the same failure, but didn't :)
[19:40] <mterry> Saviq, the previous code did the same thing, panel.indicators also isn't sibling/parent of the edge demo
[19:40] <Saviq> mterry, yes it is, that's the first argument to createObject
[19:42] <mterry> Saviq, right, I forgot I placed each overlay object into its target object
[19:42] <Saviq> jeez why is U1 so slow :(
[19:42] <mterry> Saviq, OK.  I guess that's a simple fix to update the parent to be demo.indicators.content; weird that I was getting away with it
[19:42] <Saviq> mterry, we could probably just go with the Overlay having anchors.fill: parent by default
[19:42] <Saviq> mterry, and just create it as a child of whatever it's supposed to be part of
[19:43] <Saviq> mterry, but it's fine like it is, too
[19:43] <mhr3> ChrisTownsend, do you know when did the i386 failures start?
[19:43] <ChrisTownsend> It seems like last night or so.
[19:43] <ChrisTownsend> mhr3: ^^
[19:43] <mhr3> ChrisTownsend, rather, when was last successful build?
[19:43] <ChrisTownsend> mhr3: Let me try to find that out.
[19:44] <mterry> Saviq, hmm, no I remember I ran into a problem with that elsewhere.  Like topEdgeDemo wanted to be created in underlay otherwise there was input issues, but it wants to target the dash
[19:44] <mterry> but that's a sibling at least
[19:45] <mterry> Saviq, oh wait.  so is demo.indicators.content, eh?  Isn't that a sibling of the object I'm creating under demo.indicators?
[19:47] <ChrisTownsend> mhr3: Ok, these times are Eastern US times: last good build was reported at 3:41 am this morning.  First bad build was reported at 10:09am this morning.
[19:48] <mhr3> eh, where's a tz convertor when you need one :)
[19:48] <ChrisTownsend> mhr3: Yeah, really:)
[19:49] <ChrisTownsend> mhr3: Also, those are the times I received emails from Jenkins, so the times could be approximate.
[19:50] <mhr3> ChrisTownsend, you mean regular unity merge mails?
[19:50] <mhr3> last one i got is 12hours ago... hm
[19:50] <ChrisTownsend> mhr3: The emails from Jenkins CI jobs for MP's - either the initial CI or an automerge CI.
[19:51] <ChrisTownsend> mhr3: You want me to forward them to you?
[19:51] <mhr3> ChrisTownsend, this shows the times properly, right?
[19:51] <mhr3> https://jenkins.qa.ubuntu.com/job/unity-saucy-i386-ci/
[19:52] <mhr3> and you're saying last success is 276, is that correct?
[19:53] <ChrisTownsend> mhr3: This is the last good job: https://jenkins.qa.ubuntu.com/job/unity-ci/388/
[19:54] <ChrisTownsend> mhr3: This is the first fail job with the error I reported: https://jenkins.qa.ubuntu.com/job/unity-autolanding/309/
[19:55] <ChrisTownsend> mhr3: So yes, for i386, job 276 is the last good one.
[19:56] <ChrisTownsend> mhr3: For failing on i386, this is the job: http://jenkins.qa.ubuntu.com/job/unity-saucy-i386-autolanding/265
[19:56] <ChrisTownsend> mhr3: I hope that helps
[19:59] <mhr3> what would help is a i386 machine :/
[20:01] <ChrisTownsend> mhr3: We are trying to simulate the building in an i386 chroot.
[20:01] <mhr3> so am i
[20:01] <mhr3> but it's been a while that i updated it
[20:01] <Saviq> mterry, ah! sibling it is ;)
[20:02] <mhr3> will take a while
[20:03] <mhr3> ChrisTownsend, but anyway, the test-service helper crashes, would be nice to get a stacktrace where does it happen
[20:04] <ChrisTownsend> mhr3: Ok
[20:04] <bschaefer> mhr3, sooo i just finished building unity in i386 pbuilder...and there are the failures:
[20:04] <bschaefer> http://paste.ubuntu.com/6151673/
[20:04] <mhr3> bschaefer, stacktrace pls ^
[20:04] <bschaefer> no scope problems :(
[20:04] <mhr3> hmm, yea, that no good
[20:05] <mhr3> bschaefer, do you have the ppas enabled?
[20:05] <bschaefer> mhr3, its not crashing here :(
[20:05] <bschaefer> nope
[20:05] <bschaefer> mhr3, that does make sense
[20:05] <mhr3> bschaefer, enable them :)
[20:05] <bschaefer> :)
[20:05] <bschaefer> mhr3, daily build ppa right?
[20:06] <mhr3> yep
[20:06] <bschaefer> cool, ill restart that then with that ppa...
[20:44] <mhr3> bschaefer, updated my chroot, can't reproduce :/
[20:44] <bschaefer> mhr3, mines building atm :(
[20:44] <bschaefer> mhr3, though jenkins always likes to be different...
[20:45] <bschaefer> mhr3, possibly you could get an i386 machine from qa?
[20:51] <bschaefer> mhr3, yup, mine didn't hit the issue either :(
[20:55] <seb128> bschaefer, mhr3: need i386 testing for something?
[20:56] <bschaefer> seb128, yeah, for this issue:
[20:56] <bschaefer> https://jenkins.qa.ubuntu.com/job/unity-autolanding/309/
[20:56] <bschaefer> the i386 seems to be failing on scope tests
[20:56]  * bschaefer digs up bug ChrisTownsend made
[20:56] <bschaefer> https://bugs.launchpad.net/bugs/1229891
[20:57] <seb128> does that require to build unity?
[20:57] <seb128> is that current saucy or trunk?
[20:58] <bschaefer> seb128, i believe saucy with daily build ppa, and yeah unity will need to build to run the tests
[20:58] <seb128> non trivial then
[20:58] <bschaefer> as the issue seems to be in libunity, which is causing unity unit tests to fail causing the automerger to fail :(
[20:58] <ChrisTownsend> seb128: Yeah, it's also trunk.  We are blocked on automerging because of this.
[20:59] <bschaefer> but we can't reproduce the problem in chroot...
[20:59] <seb128> let me see if I can reproduce locally
[20:59] <seb128> so basically building libunity trunk then unity trunk should be enough?
[21:00] <bschaefer> seb128, as long as you have an i386 machine :)
[21:00] <bschaefer> thats the real problem we are running into...
[21:00] <seb128> yes, I'm running i386
[21:00] <bschaefer> cool, then yes that should be neough
[21:00] <bschaefer> enough*
[21:01]  * seb128 starts building
[21:01] <bschaefer> seb128, thanks!
[21:04] <seb128> bschaefer, libunity fails to build on tests here
[21:04] <bschaefer> seb128, hmm thats strange...
[21:04]  * bschaefer also doesn't know much about libunity
[21:05] <seb128> ../../test-driver : ligne 95 : 12106 Erreur de segmentation  (core dumped) "$@" > $log_file 2>&1
[21:05] <seb128> segfault
[21:05] <bschaefer> hmm
[21:05]  * bschaefer attempts to build libunity
[21:07] <bschaefer> seb128, this is just tests for libunity?
[21:07] <seb128> bschaefer, it's doing "bzr branch lp:libunity; cd libunity; bzr bd"
[21:07] <seb128> but "make check" in the build tree hits the same segfault reliably
[21:07] <bschaefer> i get a fun:
[21:07] <bschaefer> 	 -a make test-nonrecursive; \
[21:07] <bschaefer>         sleep 1;
[21:07] <bschaefer> /bin/bash: line 1: -a: command not found
[21:08] <bschaefer> seb128, when I try make check...but i know mhr3 wanted a stracktrace
 ChrisTownsend, but anyway, the test-service helper crashes, would be nice to get a stacktrace where does it happen
[21:08] <seb128> mhr3, hey
[21:08] <bschaefer> seb128, you've the daily build ppa?
[21:08] <seb128> no, current saucyt
[21:09] <bschaefer> hmm I think mhr3 mentioned the need for the daily build ppa, but that could have been for chroot only :(
[21:09] <seb128> well, I'm having the testsuit segfaulting in current saucy
[21:09] <seb128> that could be the same issue
[21:09] <bschaefer> which isn't good, yeah
[21:09] <bschaefer> seb128, would you be able to get a stacktrace and add a comment on that bug?
[21:09] <bschaefer> https://bugs.launchpad.net/bugs/1229891
[21:09] <seb128> well, I'm trying
[21:10] <seb128> but running that .py by hand doesn't segfault
[21:10] <seb128> not sure how to run "make check" under gdb
[21:10] <bschaefer> hmm neither do i, unless you know where that file is...
[21:11] <seb128> no, I'm trying to read the makefile
[21:11] <bschaefer> possibly try to figure out which test suite is failing? in test/vala...
[21:11] <seb128> would be useful to have mhr3 around
[21:11] <bschaefer> very much so :)
[21:11] <seb128> FAIL: container-ownership.py
[21:12]  * bschaefer does not know much/anything about libunity :(
[21:13] <bschaefer> well thats in test/python...
[21:13] <seb128> right
[21:17] <bschaefer> seb128, i get the same
[21:17] <bschaefer> ../../test-driver: line 95:  6877 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
[21:17] <bschaefer> FAIL: container-ownership.py
[21:17] <seb128> good
[21:17] <seb128> so you have something to debug (or mhr3 has something to debug since it's libunity)
[21:17] <bschaefer> welll then this must be un related to the i386 issue...as i have 64bit...
[21:17] <bschaefer> but it still needs to be fixed
[21:18] <bschaefer> seb128, right, would you still be able to install libunity and test unity out?
[21:18] <seb128> yes
[21:18] <bschaefer> just to see if you get unity unit-test failures?
[21:18] <bschaefer> thanks
[21:18]  * bschaefer tries it out as well
[21:18] <bschaefer> as Im not sure if i was using the right libunity
[21:19] <bschaefer> seb128, thanks again, I don't want to keep you up to late!
[21:19] <seb128> bschaefer, don't worry, I'm not really working, mostly chatting on the computer, builds can run on the side ;-)
[21:20] <bschaefer> seb128, :)
[21:30] <mhr3> seb128, you're building it with latest vala
[21:30] <mhr3> seb128, pbuilder does it correctly :P
[21:31] <seb128> mhr3, not, I'm using 0.20.1
[21:31] <mhr3> seb128, exactly, we use 0.18 to build libunity
[21:31] <mhr3> cause there are issues in 0.20
[21:31] <seb128> ok, current vala is 0.22
[21:31] <seb128> just for info :p
[21:32] <mhr3> ah, ok you win :P
[21:32] <seb128> ;-)
[21:32] <mhr3> it should work with 0.22 iirc
[21:32] <mhr3> should have the fix we need
[21:32] <seb128> vala sucks
[21:32] <mhr3> yea, yea, c++ is awesome we all know that
[21:33] <bschaefer> mhr3, im glad you agree :)
[21:35] <mhr3> bschaefer, sorry, didn't realize it needs a <sarcasm> tag :P
[21:35] <bschaefer> mhr3, haha, i got it, but I suppose i needed a <joking> tag as well
[21:35] <seb128> mhr3, it's so great that I started that build 15 minutes ago and unity is still not half built
[21:36] <mhr3> seb128, and that's only one of the great features ;)
[21:36] <bschaefer> mhr3, but wait theres more!
[21:36]  * bschaefer has watched to many infomercials
[21:38] <mhr3> seb128, do you know if there are any other ppas the autolanding jobs use besides daily-build?
[21:38] <seb128> not that I know, why?
[21:40] <mhr3> cause isn't using trunks for the stack, and the daily build ppa is... you know... daily
[21:40] <mhr3> it's using*
[21:58] <seb128> bschaefer, mhr3: no test issue here :/
[21:59] <seb128> on that note I'm calling it a day
[21:59] <seb128> bye
[21:59]  * bschaefer wonders if its jenkins falut
[21:59] <bschaefer> seb128, thanks!
[21:59] <bschaefer> fault*
[21:59] <mhr3> seb128, thx for checking cu
[22:00] <mhr3> bschaefer, is there a way to have jenkins run through a branch without actually approving it?
[22:00]  * mhr3 has an idea
[22:03] <bschaefer> mhr3, hmm there use to be
[22:03] <bschaefer> veebers, ping?
[22:04] <bschaefer> mhr3, if you link me a branch i can try to push it onto someone to test it
[22:11] <mhr3> bschaefer, actually i think if you'd just approve it
[22:11] <bschaefer> mhr3, i can do that as well :)
[22:11] <mhr3> but not top-approve it'd run
[22:11] <bschaefer> yeah, sounds like a good idea
[22:11] <mhr3> let me prepare the branch
[22:11] <bschaefer> cool
[22:15] <mhr3> bschaefer, https://code.launchpad.net/~unity-team/unity/get-some-debug/+merge/187377
[22:15] <bschaefer> mhr3, done, and have a good night :)
[22:16] <mhr3> it's not even midnight yet :P
[22:16] <bschaefer> unless you want to stick around for it to output some fun
[22:16] <bschaefer> :), thats true here as well!
[22:17] <mhr3> oh wait, the change that happened is that we run on real hw now, right?
[22:18] <mhr3> so... yey for uncovered threading issues maybe?
[22:19] <bschaefer> hmm im not sure, but its consistent? You would think it would be easy to reproduce else where though right?
[22:19] <bschaefer> as seb ran it on his machine (im assuming hw)
[22:27] <mhr3> dunno, lets wait for the trace, but the error is pretty weird
[22:27] <mhr3> plus only on i386... :/
[22:30]  * bschaefer didn't actually look at the error yet ...
[22:31] <bschaefer> the stacktrace would be nice :)
[22:31] <bschaefer> will*
[22:42] <veebers> bschaefer: pong
[22:52] <bschaefer> veebers, unpong!
[22:52] <veebers> bschaefer: ^_^ ack
[22:52] <bschaefer> thanks :)