[08:37] <mhr3> Saviq, ok for me to build new scopes stuff in ppa:unity-team/ppa?
[08:37] <mhr3> Saviq, want to have latest stuff available for trusty
[09:03] <mhr3> Saviq, re the no form factor thing - ultimately you still have "currentShellConfiguration", don't you? that is enough for us
[09:03] <mhr3> we don't care how you make the decision
[09:03] <mhr3> and if that doesn't match the device type... we don't care
[09:22] <Saviq> mhr3, you won't be able to build u8 on trusty without new qt package names
[09:23] <Saviq> mhr3, wth is "currentShellConfiguration"? ;)
[09:25] <mhr3> Saviq, i just want scopes, trusty u8 will have to be enough for now :)
[09:26] <mhr3> and it's whatever layout type your smart thing + user decided to use
[09:28] <Saviq> mhr3, grep comes up empty ;), or is that in the API simply?
[09:29] <mhr3> Saviq, that's what i just decided to call it now
[09:29] <mhr3> Saviq, as i said ^^ shell's current layout
[09:29] <Saviq> mhr3, yeah, we'll need to come up with a proper name for that
[09:29] <Saviq> mhr3, I'd leave it be formFactor for now
[09:30] <mhr3> a bit misleading, but fine by me
[09:30] <Saviq> mhr3, the values will be different anyway, so we'll deprecate that part of the API in due time
[09:30] <Saviq> mhr3, and introduce a new, proper one for the new thing
[09:30] <mhr3> Saviq, any clue already what the new values will be?
[09:31] <mhr3> or what they'll look like?
[09:31] <mhr3> will it be things like "touch-optimized" etc?
[09:34] <Saviq> mhr3, if I have my way, it will be touch, windowed, 10feet, or some such
[09:34] <Saviq> mhr3, names TBD
[09:34] <mhr3> k
[09:34] <Saviq> mhr3, we're sending frameworks to the store atm anyway, right?
[09:35] <mhr3> no idea
[09:35] <mhr3> pstolowski, ^?
[09:35] <Saviq> mhr3, so for the most important thing - apps - form factor or The Other Thing™ is not enough anyway
[09:35] <pstolowski> Saviq, yes, we do
[09:35] <Saviq> so TBH I'd drop formFactor from the API sooner rather than later
[09:36] <mhr3> but that'd be api break :P
[09:44] <Mirv> Saviq: will tsdgeos be around today? I built the 5.3 qtdeclarative with delegate patch and the tsdgeos' unity8 branch, but I'm getting just a crash loop over there
[09:44] <Saviq> Mirv, no, he's out
[09:45] <Saviq> Mirv, ok, let's leave it until Monday then
[09:45] <Saviq> Mirv, maybe we'll get feedback upstream
[09:45] <Mirv> on 5.2 with the backported qtdeclarative patch and the same unity8 branch I have stuff running, although there might be something wrong (I've only just started tests, but a _lot_ of UI Toolkit tests failed, unless my cats interfered or something)
[09:46] <Saviq> Mirv, ah, so it could be 5.3 specific then?
[09:46] <Mirv> Saviq: well the crash thing yes. it just may be that it's faulty also on 5.2.
[09:47] <Mirv> Saviq: for reference, qt5-beta2 has the "normal" stuff still regarding 5.3 (unity8 starts, but scopes broken), while qt5-daily has the same otherwise but updated qtdeclarative + unity8
[09:47] <Saviq> Mirv, ok thanks
[09:48] <Saviq> seb128, bug #1320160
[09:50] <seb128> Saviq, thanks ... likely not our bug, that code didn't change since january and was working fine
[09:50] <seb128> but I can try having a look at what change
[09:50] <seb128> likely qt
[09:52] <Saviq> seb128, k
[10:01] <Saviq> dednick, https://code.launchpad.net/~saviq/unity8/cmake-plugin-cleanup/+merge/218171 Approved → Needs Review for a reason?
[10:02] <dednick> Saviq: i switched to Approved, but there's still alberts review pending.
[10:02] <dednick> so i switched back
[10:03] <Saviq> dednick, he only complained about a conflict ;)
[10:03] <Saviq> but yeah, your call
[10:03] <dednick> Saviq: "Are the approvals equal to or greater than the disapprovals?"  -NO!
[10:03] <dednick> :)
[10:03]  * Saviq kicks the bot :P
[10:04] <Saviq> it should be working this morning
[10:04] <dednick> Saviq: couldnt be bothered. just approved it
[10:04] <Saviq> ;)
[10:12] <pete-woods> Cimi: just letting you know that I revised the path that the fake json file needs to go in
[10:12] <pete-woods> Cimi: instead of the cache directory (naughty pete), the hooks are supposed to install stuff in ~/.local
[10:13] <pete-woods> so you'll now need to create ~/.local/share/libusermetrics/sources/foo.json instead
[10:28] <Cimi> pete-woods, thanks
[11:23] <mt_caret> Is anybody here?
[11:24] <mt_caret> I'm new to IRC, but I problems with unity, it'll be great if someone could help me
[11:24] <mt_caret> *I have problems
[11:26] <mt_caret> anyone?
[11:26] <Saviq> mzanetti, you said there was still an issue with short appid, greyback just ACK'ed the branch, so what's the deal?
[11:26] <Saviq> mt_caret, just ask your questions
[11:26] <mt_caret> k, well I just booted and the launcher was gone.
[11:27] <mt_caret> so I switched to a terminal and started ccsm
[11:27] <greyback> Saviq: I approved the unity8 changes because they're good. It's unity-mir which needed fixing. I pushed fix for it, we're testing it now
[11:27] <mt_caret> checked all the options, but nothing happened.
[11:27] <Saviq> greyback, kk
[11:27] <mzanetti> Saviq: packages building, testing soon
[11:27] <Saviq> mt_caret, if you press against the left edge, does it show up?
[11:27] <mt_caret> nope
[11:27] <mt_caret> well, I tried unity from the command line, and it failed
[11:28] <mt_caret> saying compiz couldn't load opengl
[11:28] <mt_caret> even though ccsm says its on.
[11:28] <mt_caret> but then when I just executed 'compiz'
[11:28] <mt_caret> opengl loads normally, and I get a unity launcher
[11:28] <Saviq> mt_caret, if you log in to the guest session from the greeter, does everything work?
[11:29] <mt_caret> haven't tried that, I'll check...
[11:34] <mt_caret> just tried it out, and it looks like i do get unity in the guest session
[11:35] <mt_caret> btw, exec unity, then ctrl-c and then compiz gets my launcher back, but without any of the indicators in the top right
[11:36] <Mirv> ok there was something wrong with my previous AP run, now UITK passed this time
[11:42] <mt_caret_> oh, and I also can't launch the terminal emulator after getting a launcher, it disappears in a flash
[11:48] <greyback> Saviq: gentle reminder: https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721 :)
[11:48] <Saviq> greyback, on it right now
[11:48] <greyback> Saviq: thanks
[11:48] <Saviq> greyback, only just found that unity8 crashes under wrong locale so want to file a bug on that first
[11:49] <Saviq> well, aborts, not crashes
[12:21] <mhr3> saviq, btw will you add the scope-tool update to any of your u8 landings, or are you excepting me to do it?
[12:21] <Saviq> mhr3, I will
[12:21] <mhr3> k, ty
[12:21] <Saviq> mhr3, might not be today, Monday latest
[12:22] <mhr3> i waited a week, can do one more day :P
[12:22] <Saviq> mhr3, pfft! it only got approved... 3 days ago ;P
[12:23] <Saviq> mhr3, it's mzanetti's and greyback's fault! I tell you!, they've been hogging a unity8 silo for 3 days now!
[12:23] <mzanetti> and still hogging it
[12:23] <mhr3> saviq, tell them off then, you're their lead! :)
[12:23] <Saviq> mhr3, good news is that there's no more manual intervention required to migrate unity8 from -proposed
[12:24] <Saviq> mhr3, hint hint, I just did! ;D
[12:24] <mhr3> saviq, too subtle :)
[12:24] <mzanetti> yes. too subtle
[12:25] <mzanetti> no seriously... we're working on it... but we shouldn't land it before issues are fixed
[12:26] <Saviq> mzanetti, no indeed, but we might need to switch it into override mode, when we can land stuff in parallel
[12:26] <Saviq> mzanetti, or get it out of the silo for that matter, until you confirmed fixes locally
[12:26] <mzanetti> Saviq: what's the issue actually?
[12:26] <mzanetti> Saviq: why can't we have multiple silos?
[12:27] <Saviq> mzanetti, because you have to serialize *somewhere*
[12:27] <Saviq> mzanetti, and currently silos are where we try to serialize
[12:27] <mzanetti> ah I see
[12:27] <Saviq> mzanetti, i.e. a single component in-flight in multiple silos is meant to be an exception, not a rule
[12:27] <mzanetti> mhm... ok
[12:27] <Saviq> because then you land one of them and have to rebuild / retest the rest anyway
[12:28] <mzanetti> I really hope we have it soon. but just found another issue in what I thought would be the last test run. but fix already committed and its rebuilding
[12:30] <Saviq> mzanetti, FWIW, it actually takes longer to rebuild in silo than cross-build locally
[12:30] <mzanetti> yeah... you might be right there
[12:31] <mhr3> saviq, but setting up and keeping cross-building working... :(
[12:31] <Saviq> mhr3, huh?
[12:31] <Saviq> mhr3, if we don't use it, it won't work, that's how it is
[12:31] <Saviq> mhr3, not the other way around
[12:32] <mhr3> true, but it still feels overly complicated
[12:32] <mhr3> i can't imagine regular developers actually doing it, and somehow we expect them to
[12:32] <mzanetti> I tend to agree with that
[12:32] <Saviq> mhr3, "click chroot create foo"
[12:32] <Saviq> mhr3, that's what regular developers do
[12:32] <Saviq> mhr3, *we* need a bit more for dpkg reasons
[12:33] <Saviq> mhr3, and what's more, click chroot support is integrated into qtcreator
[12:33] <mzanetti> yep, true. there's definitely progress
[12:33] <mzanetti> altough I haven't managed to use it from qtcreator yet.
[12:34] <mzanetti> haven't send too much time trying tho
[12:34] <Saviq> mhr3, mzanetti, it's a 15-minute set-up time for multi-hour savings over the course of a cycle... really?
[12:34] <mzanetti> spend
[12:34] <Saviq> spent
[12:34] <mzanetti> :D
[12:34] <mzanetti> I have the sbuild thing running...
[12:34] <mhr3> saviq, yea, i noticed, but honestly when i tried to build an app that used a lib that we have in archive but isn't qt, i couldn't figure out how i'd do that
[12:34] <mzanetti> and I even use it sometimes
[12:35] <Saviq> mhr3, right, BYOB is still a problem
[12:35] <Saviq> mhr3, but is a problem whether you're cross-building or not
[12:35] <mhr3> BYOB?
[12:35] <Saviq> bring your own binaries
[12:36] <mhr3> yea, but apps are pretty useless without those :)
[12:36] <mhr3> qt has things... but
[12:36] <mhr3> not those 10k of libs that we normally have :)
[12:36] <Saviq> mhr3, yeah, again, how is that related to cross-building? ;)
[12:37] <mhr3> diverged a bit :)
[12:37] <mhr3> saviq, but yea the problem is that even your simple sbuild is 3 A4 pages of instructions :P
[12:38] <Saviq> mhr3, most of which optional
[12:38] <mhr3> saviq, time for RealSimpleSBuild then :)
[12:38] <Saviq> mhr3, and again, it's only 15 mins setup, for multi-hour savings over the cycle
[12:39] <mzanetti> its 15 mins to setup when you know what you're doing. certainly not the first times you set it up
[12:39] <mzanetti> but yes... I still agree we should do it
[12:39] <mzanetti> but also agree with mhr3 that its not easy enough yet
[12:39] <dednick> Saviq: i'm going to miss standup today. I'll put my notes in.
[12:39] <Saviq> dednick, kk
[12:40] <Saviq> mzanetti, if there are issues in the wiki, needs fixing - it indeed mentioned --arch= instead of --target=, which was your main issue
[12:41] <mhr3> saviq, could you maybe do a cross-building presentation in malta?
[12:41] <mhr3> demo*
[12:42] <Saviq> mhr3, wonder if a workshop would be of better ues
[12:42] <Saviq> use
[12:42] <mhr3> take vanilla trusty/utopic and have armhf binaries of u8 or something by the end
[12:42] <Saviq> I wonder if I could use the click chroots, that would simplify things a bit
[12:43] <mzanetti> +1
[12:43] <Saviq> I'll see what I can do
[12:47] <Saviq> greyback, we're ignoring the fact that you can see the old app when respawning for now?
[12:48] <greyback> Saviq: no change there, it was like that before
[12:48] <Saviq> greyback, less visible since we were never respawning, but yeah
[12:48] <Saviq> hmm I just lost one app again...
[12:49] <Saviq> greyback, the weird thing is that sometimes you can see black, sometimes old app... not sure what's that about
[12:49] <Saviq> maybe if both old and new were killed I think
[12:51] <Saviq> xnox, you're in Malta second week, could we have you for a bit in a "Cross-building workshop" session so that you explained Multi-Arch: and Dep qualifiers?
[12:51] <Saviq> +tried to
[12:52] <xnox> Saviq: ok.
[12:52] <Saviq> xnox, awesome, thanks
[12:56] <Saviq> looks like we could use click chroots indeed
[13:11] <Saviq> greyback, hmm, app with --desktop_file_hint... Ctrl+C, app gets restarted, that expected?
[13:12] <greyback> Saviq: no
[13:12] <Saviq> greyback, this must be a fallout of the last fix :|
[13:14] <greyback> Saviq: how you mean get restarted?
[13:14] <Saviq> greyback, I believe it takes the .desktop file and relaunches based on that
[13:14] <Saviq> greyback, so I don't have the app in console any more
[13:15] <Saviq> greyback, but it launches the one by desktop file
[13:15] <greyback> Saviq: if you Ctrl+C something you manually launched with dfh, it does stay in the list of apps
[13:15] <Saviq> greyback, yeah, it does
[13:15] <greyback> which is unfortunate, but I can't fix that *and* the issue you found yesterday
[13:15] <greyback> they conflict
[13:15] <Saviq> greyback, and then it gets restarted when I tap on it...
[13:15] <Saviq> greyback, yeah I figured as much :/
[13:16] <Saviq> greyback, just not sure which is worse...
[13:16] <greyback> Saviq: I had thought it would be an ok compromise , but now i'm not so sure
[13:17] <Saviq> greyback, it *might* actually be ok
[13:17] <Saviq> greyback, it's a rather special case, too - more special than webapps
[13:17] <greyback> Saviq: if you open accounts from Settings, can you close it? Does it act "normal"
[13:17] <greyback> (I suspect accounts launches with desktop_file_hint somehow)
[13:17] <Saviq> greyback, it does
[13:18]  * Saviq tries
[13:18] <Saviq> greyback, seems to behave fine
[13:18] <greyback> Saviq: I'll have to leave it to you as a judegment call. Right now, I don't have any bright idea on fixing it (not so say such a possibility exists).
[13:19] <Saviq> greyback, weird thing, though... accounts exit fine (after their 5s grace period)
[13:19] <Saviq> greyback, and they go away from the stack... why wouldn't a manually started app :/
[13:20] <Saviq> greyback, does it depend on exit code?
[13:20] <greyback> Saviq: no. Now I'm confused, that should not be possible.
[13:20] <Saviq> greyback, same for mediaplayer app, if you launch it, it closes and goes away from the stack
[13:21] <Saviq> greyback, maybe because they're focused?
[13:22] <Saviq> greyback, I'll write down unexpected things on the MP
[13:23] <Saviq> greyback, yeah, as long as they exit when focused, they just go away
[13:23] <Saviq> greyback, but if they're suspended in the mean time, they get relaunched on focus
[13:23] <greyback> Saviq: makes sense, unity-mir assumes if an app that's focused closes, then it cannot be lifecycle restored
[13:24] <greyback> but if unfocused, the app has been given time to save state, so in theory it can be resumed
[13:24] <Saviq> greyback, right, so accounts will be problematic if you swipe them away
[13:24] <Saviq> greyback, they confuse the stack for sure
[13:25] <greyback> Saviq: I really don't think unity-mir get's enough information to make the correct decision, if upstart is not involved
[13:25] <Saviq> greyback, yeah I know
[13:25] <Saviq> greyback, could the fix you implemented last
[13:26] <Saviq> greyback, only have exceptions for known things - like QtWebProcess, signon-ui?
[13:27] <Saviq> greyback, it's not tragic, nothing dies etc., and only the corner cases get weird, but maybe we could limit the amount of corner cases then?
[13:27] <greyback> Saviq: it could be done I suppose. Though note https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845
[13:27] <greyback> signon-ui will improve shortly
[13:28] <Saviq> greyback, sure, when it improves we'd remove the special-case for it
[13:28] <Saviq> greyback, in both places
[13:28] <greyback> Saviq: will give it a go
[13:30] <greyback> Saviq: please add the strange behaviour you notice to the MR, I'll see what i can do
[13:46] <Saviq> greyback, https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/524957
[14:18] <mzanetti> Saviq: ok. green light on Silo 5
[14:18] <mzanetti> sorry for the delays
[14:18] <Saviq> mzanetti, kk
[14:18] <mzanetti> do I still need to ping someone from the landing team?
[14:19] <mhr3> Saviq, finally wrote down my take on departments -> http://paste.ubuntu.com/7473209/ comments?
[14:19] <Saviq> mzanetti, no
[14:19] <Saviq> mzanetti, ACK the branch, though https://code.launchpad.net/~gerboland/unity-mir/shortAppIds-0.1.9/+merge/219377
[14:20] <Saviq> mhr3, hmm hmm
[14:21] <Saviq> mhr3, didn't request for departments require the canned query itself?
[14:21] <mhr3> Saviq, maybe... let's say that depId == cannedQuery
[14:22] <mhr3> afterall canned query is serializable
[14:22] <Saviq> mhr3, so it looks like my original plan basically stands ;)
[14:22] <mhr3> with some tiny changes
[14:22] <Saviq> mhr3, only you don't want a separate Model
[14:23] <Saviq> mhr3, but just make Department a model, fine with that
[14:23] <mhr3> need to dig up your proposal again :)
[14:23] <Saviq> mhr3, http://pad.ubuntu.com/dash-departments-shell-api
[14:23] <mhr3> thx
[14:24] <Saviq> mhr3, not sure we need hasDepartments, though
[14:24] <Saviq> mhr3, and I think it should be the object itself straight away
[14:24] <mhr3> yea, it's wildly similar to yours :)
[14:25] <mhr3> Saviq, i actually wanted to hide it more there
[14:25] <Saviq> mhr3, why? we'd be loading it straight away anyway?
[14:25] <mhr3> Saviq, you wouldn't be able to use it anyway, cause it would update to always the current query, and you couldn't do your transition thing
[14:25] <Saviq> mhr3, sure I could
[14:26] <Saviq> mhr3, ah well, ownership
[14:26] <Saviq> mhr3, ok
[14:26] <Saviq> mhr3, but let's drop the bool
[14:26] <mhr3> the bool is necessary :)
[14:26] <Saviq> no it isn't, just make the departments prop empty if there's no department ;)
[14:27] <mhr3> Saviq, i'm not sure i can, it will be probably serialized canned query, and empty could mean either not loaded yet, or parent, or no departments
[14:27] <mhr3> too much ambiguity
[14:28] <mhr3> s/parent/root/
[14:28] <Saviq> hasDepartments would have the exact same ambiguity
[14:28] <Saviq> it'd be false until loaded
[14:28] <Saviq> without knowing whether they'd ever be loaded
[14:29] <mhr3> but you can nicely bind to the widget's visible prop
[14:29] <Saviq> yeah, with department != "", too ;)
[14:29] <Saviq> or whatnot
[14:29] <mhr3> yea.. no :)
[14:29] <Saviq> mhr3, this just adds another property to be listened to Changed signals
[14:30] <mhr3> Saviq, should be the only one really
[14:30] <Saviq> mhr3, "department" will be a property, too
[14:30] <Saviq> mhr3, will have a Changed signal
[14:30] <mhr3> but you don't need change notifications on the currentDep
[14:30] <Saviq> mhr3, bleh
[14:30] <Saviq> mhr3, please no bool
[14:31] <mhr3> bools are good!
[14:32] <Saviq> mhr3, sure, when they're not useless ;)
[14:32] <mhr3> i wouldn't add it if i thought the other prop is enough
[14:32] <Saviq> mhr3, you still haven't convinced me why it's not enough
[14:33] <mhr3> i told you
[14:33] <mhr3> department == "" is either no departments or root
[14:33] <mhr3> no way to distinguish
[14:33] <Saviq> mhr3, yeah, and? you won't know whether there are departments until you receive them anyway
[14:34] <Saviq> mhr3, anyway, not sure what's "or root", root has departments, doesn't it?
[14:34] <mhr3> Saviq, sub-, yes, but id-wise, it can't be distinguished from no-departments
[14:35] <sil2100> mzanetti: publishing 005 - double checking, is everything ok?
[14:35] <Saviq> mhr3, hmm you mean the root node won't have a department id?
[14:35] <mhr3> Saviq, yes
[14:35] <mhr3> it won't
[14:36] <Saviq> mhr3, bleh :|
[14:36] <mzanetti> sil2100: yep. all good
[14:37] <Saviq> mhr3, so anyway, the actual arg to getDepartment() will be a string will it? serialized canned query?
[14:37] <mterry> Saviq, you mentioned catching up and planning silo 002's landing.  So I've gotten all the branches approved except two: the unity8 one (which Albert said he'd approve with one small tweak, made the tweak, and then he went EOD I think :) and indicator-network, and a developer of that said he'd review today).  I'm rebuilding the silo today, should be all good
[14:37] <mhr3> Saviq, yep
[14:38] <Saviq> mhr3, bleh for not being able to do null QString ;)
[14:38] <mhr3> Saviq, or dep id, i still need to check the api expects... anyway.. some kind of string
[14:38] <Saviq> mterry, awesome, so let's plan for Monday for testing and landing?
[14:38] <mterry> Saviq, sure.  I'll continue poking at it in the meantime
[14:39] <Saviq> mterry, I'll try and clear the current queue before then
[14:39] <Saviq> mhr3, ohkay ohkay, have your bool ;(
[14:39] <mhr3> \o/
[14:40] <Saviq> mhr3, please MP against unity-api (prereq on Albert's)
[14:40] <mhr3> Saviq, i'll do it in -shell first to see whether it really fits
[14:40] <Saviq> mhr3, sure, just make it so that they all land together (-api, -shell and unity8)
[14:41] <Saviq> mhr3, or well, -api lands before the other two
[14:41] <Saviq> at least
[14:41] <mhr3> Saviq, yea.. thx for making that harder :P
[14:41] <Saviq> mhr3, that's the whole idea! (to make it harder to break API) ;P
[14:41] <mhr3> your evil plans!
[14:43] <mhr3> oh i missed the loaded prop
[14:45] <Saviq> mhr3, yeah, status
[14:46] <Saviq> mhr3, I'll modify the pad then
[14:46] <Saviq> mhr3, to get on the same page
[14:46] <mhr3> ok, thx
[14:48] <mhr3> Saviq, why did you want special error state for departments?
[14:48] <mhr3> errors are per-search, not dep-specific
[14:48] <mhr3> shouldn't be there imo
[14:48] <Saviq> mhr3, right, this was probably when I thought a query for departments could fail
[14:49] <Saviq> mhr3, when now it'd just be a generic query fail
[14:50] <Cimi> Saviq, I changed the animation of the crossfade with a parallel animation composed of two animation for the different 2 images running in parallel - I'd like to disable one of these when I am using the two different transitions, how would you disable one NumberAnimation without hacks?
[14:50] <Saviq> mhr3, WHAT DID YOU DO! ;P\
[14:50] <mhr3> whoops :)
[14:50] <mhr3> it's back :)
[14:51] <Saviq> mhr3, think we need Model in DepartmentModel? I'm fine without it
[14:51] <mhr3> whatev
[14:51] <Saviq> ok, no, then
[14:51] <Saviq> Cimi, what are they triggered by?
[14:52] <Cimi> Saviq, swapImage function calling start
[14:52] <Saviq> Cimi, then don't call start :)
[14:52] <Cimi> Saviq, but I put them inside a parallelAnimation
[14:53] <Cimi> Saviq, and I can't call start on a not-root animation
[14:53] <Saviq> Cimi, right, then just unset the target probably
[14:53] <Cimi> so if I have Parallel { Number { image1 } Number { image2 } }
[14:53] <Cimi> Saviq, which was what I called "hack"
[14:53] <Saviq> Cimi, you could override the animations parent
[14:54] <Saviq> Cimi, so Number { parent: foo ? something : parallel }
[14:54] <Saviq> Cimi, that should work I think
[14:54] <Cimi> mmm
[14:55] <Cimi> Saviq, so this is the code I am talking about
[14:55] <Cimi> http://paste.ubuntu.com/7473365/
[14:55] <Saviq> mhr3, do we need "id" at all then?
[14:55] <Cimi> Saviq, what I want is not to run currentImageFadeOut when I ran the parent
[14:57] <Saviq> Cimi, yeah, put "parent: realCrossFade ? nextImageFadeIn : somethingElse" in  currentImageFadeOut
[14:57] <Cimi> I try
[14:57] <Saviq> Cimi, I'm not *sure* that will work, but you can try
[14:58] <Saviq> Cimi, otherwise you could create that animation dynamically and destroy it on realCrossFadeChanged
[14:58] <mhr3> Saviq, hm, the api has both ids and canned queries, so i think the plugin will expose just the ids
[14:58] <Saviq> Cimi, but not sure that'd really be that much better
[14:58] <Saviq> mhr3, ah so you'd handle queries down there?
[14:58] <Cimi> Saviq, I might be able to change the property affected
[14:58] <mhr3> Saviq, yep
[14:59] <Cimi> or change target
[14:59] <Saviq> Cimi, that was what you called "hack" just a second ago ;)
[14:59] <Cimi> yeah but who cares :D
[14:59] <Cimi> unless we have better idea
[14:59] <Saviq> Cimi, apparently you do :D
[14:59] <Cimi> haha
[14:59] <Saviq> Cimi, the only "better" idea was to move the animation outside of the parallel
[14:59] <Cimi> yeah
[14:59] <Saviq> Cimi, so that it doesn't get ran at all
[15:00] <Cimi> Saviq, I could have two animations running
[15:00] <Cimi> and call what I want
[15:00] <Saviq> mhr3, so we don't need runQuery, it will just be "close" basically
[15:00] <Cimi> not sure which is better
[15:00] <Saviq> mhr3, ah, leaf nodes
[15:00] <mhr3> Saviq, we still need activateDepartment()
[15:01] <mhr3> which is pretty much runQuery()
[15:01] <Saviq> mhr3, yeah, renamed
[15:01] <Saviq> mhr3, made it gotoDepartment(string id), k?
[15:01] <mhr3> i'm still wondering how that one could be merged with getDepartmentModel()
[15:02] <Saviq> mhr3, well, in theory I could getDepartment() and close
[15:02] <mhr3> i mean gotoDepartment could return new DepartmentModel
[15:02] <Saviq> mhr3, scary
[15:03] <Saviq> mhr3, I'd rather you departmentChanged
[15:03] <mhr3> Saviq, well cause right now you're expected to do getDepartmentModel(foo); gotoDepartment(foo)
[15:03] <Saviq> mhr3, hmm as long as ids are static
[15:04] <mhr3> feels wrong
[15:04] <mhr3> but if getDepModel is gone, i'm not sure how to the initial query for departments
[15:04] <Saviq> mhr3, not really
[15:04] <Saviq> mhr3, I do gotoDep(foo); closeUI()
[15:05] <Saviq> mhr3, you then do depChanged() → I do getDep()
[15:05] <mhr3> Saviq, what if it's a hasChildren node?
[15:05] <Saviq> mhr3, same
[15:05] <Saviq> mhr3, ah you mean when you press "all foo"?
[15:05] <mhr3> but you shouldn't close the dep ui when navigating
[15:05] <mhr3> at least that's what mike said as some point
[15:05] <Saviq> mhr3, yeah, I'd only close when it's a leaf node
[15:06] <mhr3> right
[15:06] <Saviq> mhr3, well, I'd close on press on "All foo" *or* leaf node *or* the top button
[15:06] <Saviq> mhr3, on leaf node I'd *also* do gotoDep()
[15:07] <mhr3> Saviq, i'm not sure about the gotoDep() -> depChanged() -> getDep()
[15:07] <mhr3> i was thinking getDep() -> gotoDep()
[15:07] <mhr3> cause the first one will take long
[15:07] <Saviq> but why would I getDep
[15:07] <Saviq> mhr3, I wouldn't need gotoDep() then
[15:08] <Saviq> mhr3, since getDep() would already give me everything
[15:08] <mhr3> Saviq, cause you can get the subtree right away and it will be filled
[15:08] <Saviq> mhr3, gotoDep() would at that point equal closeUI
[15:08] <Saviq> mhr3, since you'd already have loaded results for it
[15:08] <Saviq> because of getDep()
[15:09] <Saviq> mhr3, the only problem I see with that is
[15:09] <Saviq> mhr3, when I go getDep(), you query the scope
[15:09] <mhr3> no
[15:09] <Saviq> yes?
[15:09] <Saviq> mhr3, you want me to gotoDep() on _every_ dep change? why?
[15:10] <mhr3> no, i'll just snapshot what i know about the dep tree at that point
[15:10] <Saviq> mhr3, if you don't know anything about the tree, you'd query it anyway
[15:10] <Saviq> mhr3, and got deps and results back
[15:10] <mhr3> but i can't just query the tree, i'll get results too
[15:10] <Saviq> mhr3, so whether you query scope or cache - your call
[15:10] <Saviq> mhr3, exactly
[15:10] <Saviq> mhr3, we *need* the results, too
[15:11] <Saviq> mhr3, as they're meant to update all the time when you browse deps
[15:11] <mhr3> right
[15:11] <mhr3> so you wanted to call gotoDep only when going to a leaf?
[15:11] <Saviq> yeah
[15:11] <mhr3> why do we even need that then :)
[15:12] <Saviq> mhr3, so, again
[15:12] <mhr3> i don't care about the close
[15:12] <mhr3> you own the model, just destroy it when you don't need it
[15:12] <Saviq> mhr3, yeah, but my only problem was Scope.departmentChanged
[15:12] <Saviq> mhr3, which you'd emit, would you
[15:13] <mhr3> i would, but i didn't think you'd actually need it
[15:13] <Saviq> mhr3, I wouldn't *need* it
[15:13] <dandrader> mzanetti, so you're planning on make lp:~mir-team/qtmir/trunk use cmake instead of qmake?
[15:13] <Saviq> mhr3, that's exactly my point :)
[15:13] <Saviq> mhr3, I'd have to differentiate between "standard" depChanged when you change searches and such
[15:13] <mzanetti> dandrader: we definitely should do that at some point. greyback already has a branch for that, but said there would be roadblockers
[15:14] <mzanetti> dandrader: I haven't tried myself yet
[15:14] <Saviq> mhr3, and "browse" depChanged when you just load the dep for current query
[15:14] <dandrader> mzanetti, so I should now start pushing my changes there?
[15:14] <Saviq> mhr3, *but*
[15:14] <mzanetti> dandrader: yes
[15:14] <mhr3> Saviq, right, right, i kinda forgot about that
[15:14] <Saviq> mhr3, since it's a string, I could in theory ignore it
[15:14] <Saviq> mhr3, in case my current dep is equal to it
[15:15] <dandrader> mzanetti,ok,  because that s/qmake/cmake is a quite intrusive, potentially clashing with my changes. so it scares me a bit :)
[15:15] <mhr3> Saviq, i wanted to just update the model i gave you, but i can't really do that
[15:15] <greyback> dandrader: mzanetti: I mostly hit walls with cmake as I don't think people usually use it to compile a QPA. Have struggled a bit with it
[15:15] <Saviq> mhr3, well, you could, if you could, but you can't if you can't ;)
[15:15] <Saviq> mhr3, I saw your note
[15:15] <mzanetti> dandrader: if you push soon enough you'll be first anyways :D
[15:15] <Saviq> mhr3, but I think it might be too tricky
[15:15] <greyback> dandrader: I'd consider cmake a nice to have, it's far from required IMO. It's not going to land any time soon anyway
[15:15] <mhr3> Saviq, indeed
[15:16] <mzanetti> dandrader: if you do changes, please either ask me to upload a new version to the ppa, or do it yourself, however you see fit. but its not automatically updated so far
[15:16] <Saviq> mhr3, basically, I will only ever *keep* two models at most - when transitioning up or down
[15:16] <dandrader> greyback, yeah, qpa's are very tied to qt, so it makes sense to stick with qmake as it has all the secret rules for getting it installed properly
[15:16] <mzanetti> greyback, dandrader: I agree too
[15:16] <Saviq> mhr3, and whenever current changes, you'd let me know and I'd load it there and then
[15:16] <greyback> mzanetti: dandrader 2 against one, motion defeated (I'm not that upset either)
[15:17] <Saviq> mhr3, so, with that in mind... I should probably call gotoDepartment on every click
[15:17] <Saviq> mhr3, and getDepartment on departmentChanged
[15:17] <mhr3> Saviq, i think you'll need to keep comparing the currentDepId with what you last requested in getDep()
[15:17] <mzanetti> greyback: huh? I thought we all 3 agreed
[15:17] <Saviq> mhr3, indeed
[15:17] <greyback> mzanetti: yeah I do. Just being theatrical :)
[15:17] <Saviq> mhr3, feels like the only way, otherwise we'd reload it unnecessarily
[15:18] <Saviq> mhr3, in which case... gotoDeparment can go away indeed
[15:18] <mzanetti> greyback: anyways, I'd like to ask you too to push upcoming changes to lp:~mir-team/qtmir/trunk
[15:18] <mhr3> Saviq, ok, enough for now, think we went far enough, let's sort out details once we have some code :)
[15:18] <Saviq> mhr3, or we could rename getDepartment to gotoDepartment
[15:18] <Saviq> mhr3, yeah
[15:18] <Saviq> mhr3, but I agree, let's try and get rid of goto
[15:18] <mzanetti> greyback: also, as you're the one that registered the qtmir project, I think only you can set the alias for lp:qtmir to that branch
[15:18] <greyback> Saviq: haveyou the power to assign branches as the devel focus? https://code.launchpad.net/qtmir
[15:18] <Saviq> mhr3, removed it
[15:18] <mhr3> kk
[15:19] <greyback> mzanetti: unfortunately not, the Maintainer group can only do that, which I'm not on (I gave the power away)
[15:19] <mzanetti> ah, I see
[15:19] <Saviq> greyback, mzanetti, done
[15:19] <mzanetti> thanks Saviq
[15:19] <greyback> Saviq: ta
[15:21] <Saviq> mhr3, you really want "current" in "currentDepartment"?
[15:21] <mhr3> Saviq, yes!
[15:21] <Saviq> mhr3, :D
[15:21] <mhr3> although not really consistent with searchString :/
[15:22] <Saviq> oh oh, published already! :D
[15:22] <mhr3> then again, searchString isn't async
[15:22] <Saviq> :| just unity-mir
[15:23] <greyback> just?!
[15:23] <Saviq> mzanetti, greyback, is it ok that unity-mir got published alone (did one depend on the other)?
[15:23] <Saviq> greyback, if you didn't add version dependencies between them, they won't get migrated together
[15:23] <mzanetti> Saviq: shouldn't break anything (except not fixing the launcher issue yet)
[15:23] <Saviq> or bumped ABI or whatnot
[15:23] <Saviq> mzanetti, ok
[15:24] <Saviq> unity8 is still in autopkgtest
[15:24] <mzanetti> Saviq: what exactly would have been the right thing to do here?
[15:24] <mzanetti> Saviq: bump version on unity-mir and depend on that in unity8?
[15:24] <mzanetti>  >=
[15:24] <Saviq> mzanetti, that, and
[15:24] <Saviq> mzanetti, Breaks: unity8 <= foo
[15:24] <Saviq> mzanetti, in unity-mir
[15:25] <mzanetti> ok... well, if it did break it, yes. in this case its actually correct not to have the Breaks
[15:25] <Saviq> mzanetti, and/or, if ABI changed, just bump ABI
[15:25] <Saviq> mzanetti, indeed
[15:26] <Saviq> mhr3, ok, the pad is good then, I think
[15:27] <mhr3> kk
[15:28] <Saviq> paulliu, you around?
[15:28] <Saviq> paulliu, lp:~paulliu/unity8/logout still has tags, please strip with http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh
[15:31] <Saviq> mhr3, you cleared the "unity8 dependencies" ppa did you?
[15:31] <mhr3> Saviq, yea, had saucy pkgs mostly anyway
[15:31] <Saviq> mhr3, good, I'm dropping the recipes
[15:31] <mhr3> Saviq, keep the scopes-related ones pls
[15:32] <mhr3> plus i just took over some of the -saucy ones :)
[15:32] <Saviq> mhr3, were they named -saucy? ;)
[15:32] <mhr3> yea
[15:32] <Saviq> mhr3, then they're gone, sorry
[15:32] <mhr3> nvm
[15:32] <mhr3> eh, nw
[15:33] <Saviq> mhr3, could've renamed them...
[15:33] <mhr3> i did... they're -trusty now
[15:33] <Saviq> mhr3, ah then those are fine
[15:34] <Saviq> mhr3, I only dropped the -saucy ones
[15:34] <Saviq> good, so everyone did right!
[15:34] <Saviq> except launchpad...
[15:34] <mhr3> we're just awesome
[15:34] <Saviq> fooking timeout :|
[15:34] <mhr3> heh
[15:36] <mhr3> grr, so ditching this stupid wifi over the weekend
[15:36] <mhr3> hopefully i won't kill my laptop :)
[15:37] <mhr3> otherwise i'll consider it Cimi's fault :P
[15:53] <paulliu> Saviq: ok
[15:55] <paulliu> Saviq: BTW, How to push if I clear the tags?
[15:55] <Saviq> paulliu, you need to run the script passing lp:~paulliu/unity8/foo to it
[15:55] <Saviq> paulliu, it will iterate over the arguments
[15:56] <paulliu> Saviq: ah.. ok
[15:56] <Saviq> paulliu, so you can just run it with "/path/to/your/local/checkout lp:~paulliu/unity8/foo"
[16:00] <mhr3> mhall119, ping? the 14.04 docs didn't get updated
[16:04] <dandrader> mzanetti, since you're on the packaging etc
[16:05] <dandrader> mzanetti, have you notice that if you make qtmir with e.g.  -j4 it eventually breaks. then you issue make once again and it continues finishes successfully
[16:06] <greyback> dandrader: one of the reasons cmake is better
[16:06] <dandrader> looks like some missing build dependency. building in the wrong order I guess
[16:07] <greyback> dandrader: there's a qmake ".depends" command which can specify that one target requires another one
[16:09] <mzanetti> dandrader: fixed already
[16:09] <greyback> mzanetti: yes you did, yay for you
[16:09] <mzanetti> dandrader: although only pushed to my packaging branch
[16:09] <mzanetti> I think
[16:09] <mzanetti> anyways. its fixed and will land in a ppa near you soon
[16:11] <mzanetti> greyback: yeah, you had the depends the wrong way round
[16:11] <greyback> mzanetti: ah was that it? Bah
[16:11] <mzanetti> yep. at least in the ppa it builds now
[16:12] <mzanetti> and that's building with -j8
[16:12] <greyback> great
[16:13] <mzanetti> yay! unity8 built too!
[16:13] <mzanetti> only keyboard to go
[16:13] <greyback> mzanetti: keyboard not needed, I landed the change needed
[16:13] <mzanetti> oh! awesome!
[16:13] <mzanetti> => ppa ready to be installed for the first time
[16:13] <greyback> Don't expect any miracles
[16:14] <mzanetti> no. I expect breakage
[16:14] <greyback> the surface management in unity8 needs a bit of work still
[16:14] <mzanetti> but hey, that's what we have the ppa for. find the breakage
[16:14] <greyback> yep
[16:15] <dandrader> mzanetti, what about the changes from the "Getting it up and running" session?
[16:15] <mzanetti> dandrader: right... still to be done
[16:16] <dandrader> likely need to branch some other packages to get them in
[16:16] <greyback> dandrader: where is that doc again?
[16:16] <dandrader> https://docs.google.com/a/canonical.com/document/d/1IiHBDIW_e0qnGt-po1D2z5HJKrNhBwh6pdILeEN2sgA/edit#
[16:16] <greyback> tnx
[16:17] <dandrader> how come it's not in your faves list? :)
[16:17] <greyback> dandrader: mzanetti I'd argue those changes are not necessary just yet. I'd like to test using the standard client QPA plugins from qtubuntu first
[16:18]  * mzanetti doesn't know enough about what's changed, so doesn't argue in this case
[16:19] <mzanetti> greyback: but afaiu it won't even boot without that, no?
[16:19] <greyback> mzanetti: it will
[16:20] <greyback> mzanetti: ubuntuclient QPA plugin is the equivalent of the ubuntumirclient QPA plugin from qtubuntu
[16:20] <greyback> mzanetti: both are used by Qt applications to connect to Mir
[16:20] <mzanetti> oh i see
[16:20] <greyback> ubuntuclient just a tidied up version of ubuntuMirclient
[16:21] <mzanetti> got it
[16:21] <greyback> ubuntuclient  has a couple of small changes, which will probably make the experience better
[16:22] <greyback> (e.g. ubuntumirclient adds a white strip to the top of the application surface - which is usually hidden under the panel)
[16:22] <greyback> ubuntuclient removes that
[16:22] <greyback> but I've a branch of qtubuntu that does the same, which might be a lot easier to land - longer term
[16:23] <mzanetti> and you're still unsure if you want to replace the ubuntumirclient with ubuntuclient, or upstream changes to ubuntumirclient
[16:23] <mzanetti> I see. makes all sense
[16:23] <mzanetti> just let me know which one you want in the ppa and you'll get it
[16:24] <greyback> mzanetti: I've not tested my qtubuntu branch yet, so let's leave that decision until monday
[16:25] <mzanetti> yeah... I'm EOWing soon now
[16:25] <greyback> no worries, Have a good weekend!
[16:25] <greyback> thanks for all your help today
[16:25] <mzanetti> no problem... finally I see progress
[16:25] <mzanetti> felt really slow the last 3 days
[16:26] <greyback> oh yeah
[16:28] <dandrader> yes, reflashing got my rotation back \o/ (god knows what I f**ed up on the previous image)
[16:33] <dandrader> greyback, whall I remove qpamirserver repo to avoid confusion?
[16:33] <dandrader> shall
[16:33] <greyback> dandrader: ok
[16:35] <dandrader> will just bring  your recent "Establish object ownership with more care" commit into qtmir and them nuke it
[16:38] <greyback> dandrader: thanks!
[16:42] <mhall119> mhr3: can I just copy the 14.10 docs over top of the 14.04 docs?
[16:42] <mhr3> mhall119, yes
[16:42] <mhall119> mhr3: if there's anything that was removed between 14.04 and 14.10, I'll need to manually remove it
[16:43] <mhr3> mhall119, just added afaik
[16:44] <mhall119> ok, putting it up on 14.04 on staging first
[16:44] <mhall119> mhr3: please verify http://91.189.92.89/api/scopes/sdk-14.04/ and then I'll push them to 14.04 on production
[16:45] <mhr3> mhall119, +1
[16:46] <mhall119> ok, going to production now
[16:46] <mhr3> mhall119, i hope the new scripts aren't going to revert it back?
[16:46] <mhr3> automatically
[16:47] <dandrader> greyback, so I can remove DBusScreen from qtmir as unity-system-compositor has it, right?
[16:47] <greyback> dandrader: right
[16:47] <dandrader> ok, will do
[16:51] <mhall119> mhr3: once it's automated it'll only update the development version, not stable version
[16:51] <mhr3> mhall119, ok
[17:05] <mhall119> mhr3: please verify http://developer.ubuntu.com/api/scopes/sdk-14.04/
[17:06] <mhr3> it's ok
[17:06] <mhall119> thanks, let me know if there are any other changes you need
[17:34]  * greyback eow o/