=== salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [08:37] Saviq, ok for me to build new scopes stuff in ppa:unity-team/ppa? [08:37] Saviq, want to have latest stuff available for trusty [09:03] Saviq, re the no form factor thing - ultimately you still have "currentShellConfiguration", don't you? that is enough for us [09:03] we don't care how you make the decision [09:03] and if that doesn't match the device type... we don't care [09:22] mhr3, you won't be able to build u8 on trusty without new qt package names [09:23] mhr3, wth is "currentShellConfiguration"? ;) [09:25] Saviq, i just want scopes, trusty u8 will have to be enough for now :) [09:26] and it's whatever layout type your smart thing + user decided to use [09:28] mhr3, grep comes up empty ;), or is that in the API simply? [09:29] Saviq, that's what i just decided to call it now [09:29] Saviq, as i said ^^ shell's current layout [09:29] mhr3, yeah, we'll need to come up with a proper name for that [09:29] mhr3, I'd leave it be formFactor for now [09:30] a bit misleading, but fine by me [09:30] mhr3, the values will be different anyway, so we'll deprecate that part of the API in due time [09:30] mhr3, and introduce a new, proper one for the new thing [09:30] Saviq, any clue already what the new values will be? [09:31] or what they'll look like? [09:31] will it be things like "touch-optimized" etc? [09:34] mhr3, if I have my way, it will be touch, windowed, 10feet, or some such [09:34] mhr3, names TBD [09:34] k [09:34] mhr3, we're sending frameworks to the store atm anyway, right? [09:35] no idea [09:35] pstolowski, ^? [09:35] mhr3, so for the most important thing - apps - form factor or The Other Thing™ is not enough anyway [09:35] Saviq, yes, we do [09:35] so TBH I'd drop formFactor from the API sooner rather than later [09:36] but that'd be api break :P [09:44] 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] Mirv, no, he's out [09:45] Mirv, ok, let's leave it until Monday then [09:45] Mirv, maybe we'll get feedback upstream [09:45] 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] Mirv, ah, so it could be 5.3 specific then? [09:46] Saviq: well the crash thing yes. it just may be that it's faulty also on 5.2. [09:47] 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] Mirv, ok thanks [09:48] seb128, bug #1320160 [09:48] bug 1320160 in ubuntu-system-settings (Ubuntu) "Sorting by size in "storage" doesn't work" [Undecided,New] https://launchpad.net/bugs/1320160 [09:50] Saviq, thanks ... likely not our bug, that code didn't change since january and was working fine [09:50] but I can try having a look at what change [09:50] likely qt [09:52] seb128, k [10:01] dednick, https://code.launchpad.net/~saviq/unity8/cmake-plugin-cleanup/+merge/218171 Approved → Needs Review for a reason? [10:02] Saviq: i switched to Approved, but there's still alberts review pending. [10:02] so i switched back [10:03] dednick, he only complained about a conflict ;) [10:03] but yeah, your call [10:03] Saviq: "Are the approvals equal to or greater than the disapprovals?" -NO! [10:03] :) [10:03] * Saviq kicks the bot :P [10:04] it should be working this morning [10:04] Saviq: couldnt be bothered. just approved it [10:04] ;) [10:12] Cimi: just letting you know that I revised the path that the fake json file needs to go in [10:12] Cimi: instead of the cache directory (naughty pete), the hooks are supposed to install stuff in ~/.local [10:13] so you'll now need to create ~/.local/share/libusermetrics/sources/foo.json instead [10:28] pete-woods, thanks === MacSlow is now known as MacSlow|lunch === seb128_ is now known as seb128 [11:23] Is anybody here? [11:24] I'm new to IRC, but I problems with unity, it'll be great if someone could help me [11:24] *I have problems [11:26] anyone? [11:26] mzanetti, you said there was still an issue with short appid, greyback just ACK'ed the branch, so what's the deal? [11:26] mt_caret, just ask your questions [11:26] k, well I just booted and the launcher was gone. [11:27] so I switched to a terminal and started ccsm [11:27] 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] checked all the options, but nothing happened. [11:27] greyback, kk [11:27] Saviq: packages building, testing soon [11:27] mt_caret, if you press against the left edge, does it show up? [11:27] nope [11:27] well, I tried unity from the command line, and it failed [11:28] saying compiz couldn't load opengl [11:28] even though ccsm says its on. [11:28] but then when I just executed 'compiz' [11:28] opengl loads normally, and I get a unity launcher [11:28] mt_caret, if you log in to the guest session from the greeter, does everything work? [11:29] haven't tried that, I'll check... [11:34] just tried it out, and it looks like i do get unity in the guest session [11:35] 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] ok there was something wrong with my previous AP run, now UITK passed this time [11:42] oh, and I also can't launch the terminal emulator after getting a launcher, it disappears in a flash [11:48] Saviq: gentle reminder: https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721 :) [11:48] greyback, on it right now [11:48] Saviq: thanks [11:48] greyback, only just found that unity8 crashes under wrong locale so want to file a bug on that first [11:49] well, aborts, not crashes === alan_g is now known as alan_g|lunch [12:21] 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] mhr3, I will [12:21] k, ty [12:21] mhr3, might not be today, Monday latest [12:22] i waited a week, can do one more day :P [12:22] mhr3, pfft! it only got approved... 3 days ago ;P [12:23] 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] and still hogging it [12:23] saviq, tell them off then, you're their lead! :) [12:23] mhr3, good news is that there's no more manual intervention required to migrate unity8 from -proposed [12:24] mhr3, hint hint, I just did! ;D [12:24] saviq, too subtle :) [12:24] yes. too subtle [12:25] no seriously... we're working on it... but we shouldn't land it before issues are fixed [12:26] mzanetti, no indeed, but we might need to switch it into override mode, when we can land stuff in parallel [12:26] mzanetti, or get it out of the silo for that matter, until you confirmed fixes locally [12:26] Saviq: what's the issue actually? [12:26] Saviq: why can't we have multiple silos? [12:27] mzanetti, because you have to serialize *somewhere* [12:27] mzanetti, and currently silos are where we try to serialize [12:27] ah I see [12:27] mzanetti, i.e. a single component in-flight in multiple silos is meant to be an exception, not a rule [12:27] mhm... ok [12:27] because then you land one of them and have to rebuild / retest the rest anyway [12:28] 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 === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [12:30] mzanetti, FWIW, it actually takes longer to rebuild in silo than cross-build locally [12:30] yeah... you might be right there [12:31] saviq, but setting up and keeping cross-building working... :( [12:31] mhr3, huh? [12:31] mhr3, if we don't use it, it won't work, that's how it is [12:31] mhr3, not the other way around [12:32] true, but it still feels overly complicated [12:32] i can't imagine regular developers actually doing it, and somehow we expect them to [12:32] I tend to agree with that [12:32] mhr3, "click chroot create foo" [12:32] mhr3, that's what regular developers do [12:32] mhr3, *we* need a bit more for dpkg reasons [12:33] mhr3, and what's more, click chroot support is integrated into qtcreator [12:33] yep, true. there's definitely progress [12:33] altough I haven't managed to use it from qtcreator yet. [12:34] haven't send too much time trying tho [12:34] mhr3, mzanetti, it's a 15-minute set-up time for multi-hour savings over the course of a cycle... really? [12:34] spend [12:34] spent [12:34] :D [12:34] I have the sbuild thing running... [12:34] 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] and I even use it sometimes [12:35] mhr3, right, BYOB is still a problem [12:35] mhr3, but is a problem whether you're cross-building or not [12:35] BYOB? [12:35] bring your own binaries [12:36] yea, but apps are pretty useless without those :) [12:36] qt has things... but [12:36] not those 10k of libs that we normally have :) [12:36] mhr3, yeah, again, how is that related to cross-building? ;) [12:37] diverged a bit :) [12:37] saviq, but yea the problem is that even your simple sbuild is 3 A4 pages of instructions :P [12:38] mhr3, most of which optional [12:38] saviq, time for RealSimpleSBuild then :) [12:38] mhr3, and again, it's only 15 mins setup, for multi-hour savings over the cycle [12:39] its 15 mins to setup when you know what you're doing. certainly not the first times you set it up [12:39] but yes... I still agree we should do it [12:39] but also agree with mhr3 that its not easy enough yet [12:39] Saviq: i'm going to miss standup today. I'll put my notes in. [12:39] dednick, kk [12:40] mzanetti, if there are issues in the wiki, needs fixing - it indeed mentioned --arch= instead of --target=, which was your main issue [12:41] saviq, could you maybe do a cross-building presentation in malta? [12:41] demo* [12:42] mhr3, wonder if a workshop would be of better ues [12:42] use [12:42] take vanilla trusty/utopic and have armhf binaries of u8 or something by the end [12:42] I wonder if I could use the click chroots, that would simplify things a bit [12:43] +1 [12:43] I'll see what I can do [12:47] greyback, we're ignoring the fact that you can see the old app when respawning for now? [12:48] Saviq: no change there, it was like that before [12:48] greyback, less visible since we were never respawning, but yeah [12:48] hmm I just lost one app again... [12:49] greyback, the weird thing is that sometimes you can see black, sometimes old app... not sure what's that about [12:49] maybe if both old and new were killed I think [12:51] 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] +tried to [12:52] Saviq: ok. [12:52] xnox, awesome, thanks [12:56] looks like we could use click chroots indeed [13:11] greyback, hmm, app with --desktop_file_hint... Ctrl+C, app gets restarted, that expected? [13:12] Saviq: no [13:12] greyback, this must be a fallout of the last fix :| [13:14] Saviq: how you mean get restarted? [13:14] greyback, I believe it takes the .desktop file and relaunches based on that [13:14] greyback, so I don't have the app in console any more [13:15] greyback, but it launches the one by desktop file [13:15] Saviq: if you Ctrl+C something you manually launched with dfh, it does stay in the list of apps [13:15] greyback, yeah, it does [13:15] which is unfortunate, but I can't fix that *and* the issue you found yesterday [13:15] they conflict [13:15] greyback, and then it gets restarted when I tap on it... [13:15] greyback, yeah I figured as much :/ [13:16] greyback, just not sure which is worse... [13:16] Saviq: I had thought it would be an ok compromise , but now i'm not so sure [13:17] greyback, it *might* actually be ok [13:17] greyback, it's a rather special case, too - more special than webapps [13:17] Saviq: if you open accounts from Settings, can you close it? Does it act "normal" [13:17] (I suspect accounts launches with desktop_file_hint somehow) [13:17] greyback, it does [13:18] * Saviq tries === ted is now known as tedg [13:18] greyback, seems to behave fine [13:18] 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] greyback, weird thing, though... accounts exit fine (after their 5s grace period) [13:19] greyback, and they go away from the stack... why wouldn't a manually started app :/ [13:20] greyback, does it depend on exit code? [13:20] Saviq: no. Now I'm confused, that should not be possible. [13:20] greyback, same for mediaplayer app, if you launch it, it closes and goes away from the stack [13:21] greyback, maybe because they're focused? [13:22] greyback, I'll write down unexpected things on the MP [13:23] greyback, yeah, as long as they exit when focused, they just go away [13:23] greyback, but if they're suspended in the mean time, they get relaunched on focus [13:23] Saviq: makes sense, unity-mir assumes if an app that's focused closes, then it cannot be lifecycle restored [13:24] but if unfocused, the app has been given time to save state, so in theory it can be resumed [13:24] greyback, right, so accounts will be problematic if you swipe them away [13:24] greyback, they confuse the stack for sure [13:25] Saviq: I really don't think unity-mir get's enough information to make the correct decision, if upstart is not involved [13:25] greyback, yeah I know [13:25] greyback, could the fix you implemented last [13:26] greyback, only have exceptions for known things - like QtWebProcess, signon-ui? [13:27] 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] Saviq: it could be done I suppose. Though note https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845 [13:27] signon-ui will improve shortly [13:28] greyback, sure, when it improves we'd remove the special-case for it [13:28] greyback, in both places [13:28] Saviq: will give it a go [13:30] Saviq: please add the strange behaviour you notice to the MR, I'll see what i can do [13:46] greyback, https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/524957 [14:18] Saviq: ok. green light on Silo 5 [14:18] sorry for the delays [14:18] mzanetti, kk [14:18] do I still need to ping someone from the landing team? [14:19] Saviq, finally wrote down my take on departments -> http://paste.ubuntu.com/7473209/ comments? [14:19] mzanetti, no [14:19] mzanetti, ACK the branch, though https://code.launchpad.net/~gerboland/unity-mir/shortAppIds-0.1.9/+merge/219377 [14:20] mhr3, hmm hmm [14:21] mhr3, didn't request for departments require the canned query itself? [14:21] Saviq, maybe... let's say that depId == cannedQuery [14:22] afterall canned query is serializable [14:22] mhr3, so it looks like my original plan basically stands ;) [14:22] with some tiny changes [14:22] mhr3, only you don't want a separate Model [14:23] mhr3, but just make Department a model, fine with that [14:23] need to dig up your proposal again :) [14:23] mhr3, http://pad.ubuntu.com/dash-departments-shell-api [14:23] thx [14:24] mhr3, not sure we need hasDepartments, though [14:24] mhr3, and I think it should be the object itself straight away [14:24] yea, it's wildly similar to yours :) [14:25] Saviq, i actually wanted to hide it more there [14:25] mhr3, why? we'd be loading it straight away anyway? [14:25] 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] mhr3, sure I could [14:26] mhr3, ah well, ownership [14:26] mhr3, ok [14:26] mhr3, but let's drop the bool [14:26] the bool is necessary :) [14:26] no it isn't, just make the departments prop empty if there's no department ;) [14:27] 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] too much ambiguity [14:28] s/parent/root/ [14:28] hasDepartments would have the exact same ambiguity [14:28] it'd be false until loaded [14:28] without knowing whether they'd ever be loaded [14:29] but you can nicely bind to the widget's visible prop [14:29] yeah, with department != "", too ;) [14:29] or whatnot === alan_g is now known as alan_g|tea [14:29] yea.. no :) [14:29] mhr3, this just adds another property to be listened to Changed signals [14:30] Saviq, should be the only one really [14:30] mhr3, "department" will be a property, too [14:30] mhr3, will have a Changed signal [14:30] but you don't need change notifications on the currentDep [14:30] mhr3, bleh [14:30] mhr3, please no bool [14:31] bools are good! [14:32] mhr3, sure, when they're not useless ;) [14:32] i wouldn't add it if i thought the other prop is enough [14:32] mhr3, you still haven't convinced me why it's not enough [14:33] i told you [14:33] department == "" is either no departments or root [14:33] no way to distinguish [14:33] mhr3, yeah, and? you won't know whether there are departments until you receive them anyway [14:34] mhr3, anyway, not sure what's "or root", root has departments, doesn't it? [14:34] Saviq, sub-, yes, but id-wise, it can't be distinguished from no-departments [14:35] mzanetti: publishing 005 - double checking, is everything ok? [14:35] mhr3, hmm you mean the root node won't have a department id? [14:35] Saviq, yes [14:35] it won't [14:36] mhr3, bleh :| [14:36] sil2100: yep. all good [14:37] mhr3, so anyway, the actual arg to getDepartment() will be a string will it? serialized canned query? [14:37] 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] Saviq, yep [14:38] mhr3, bleh for not being able to do null QString ;) [14:38] Saviq, or dep id, i still need to check the api expects... anyway.. some kind of string [14:38] mterry, awesome, so let's plan for Monday for testing and landing? [14:38] Saviq, sure. I'll continue poking at it in the meantime [14:39] mterry, I'll try and clear the current queue before then [14:39] mhr3, ohkay ohkay, have your bool ;( [14:39] \o/ [14:40] mhr3, please MP against unity-api (prereq on Albert's) [14:40] Saviq, i'll do it in -shell first to see whether it really fits [14:40] mhr3, sure, just make it so that they all land together (-api, -shell and unity8) [14:41] mhr3, or well, -api lands before the other two [14:41] at least [14:41] Saviq, yea.. thx for making that harder :P [14:41] mhr3, that's the whole idea! (to make it harder to break API) ;P [14:41] your evil plans! [14:43] oh i missed the loaded prop [14:45] mhr3, yeah, status [14:46] mhr3, I'll modify the pad then [14:46] mhr3, to get on the same page [14:46] ok, thx [14:48] Saviq, why did you want special error state for departments? [14:48] errors are per-search, not dep-specific [14:48] shouldn't be there imo [14:48] mhr3, right, this was probably when I thought a query for departments could fail [14:49] mhr3, when now it'd just be a generic query fail [14:50] 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] mhr3, WHAT DID YOU DO! ;P\ [14:50] whoops :) [14:50] it's back :) [14:51] mhr3, think we need Model in DepartmentModel? I'm fine without it [14:51] whatev [14:51] ok, no, then [14:51] Cimi, what are they triggered by? [14:52] Saviq, swapImage function calling start [14:52] Cimi, then don't call start :) [14:52] Saviq, but I put them inside a parallelAnimation [14:53] Saviq, and I can't call start on a not-root animation [14:53] Cimi, right, then just unset the target probably [14:53] so if I have Parallel { Number { image1 } Number { image2 } } [14:53] Saviq, which was what I called "hack" [14:53] Cimi, you could override the animations parent [14:54] Cimi, so Number { parent: foo ? something : parallel } [14:54] Cimi, that should work I think [14:54] mmm [14:55] Saviq, so this is the code I am talking about [14:55] http://paste.ubuntu.com/7473365/ [14:55] mhr3, do we need "id" at all then? [14:55] Saviq, what I want is not to run currentImageFadeOut when I ran the parent [14:57] Cimi, yeah, put "parent: realCrossFade ? nextImageFadeIn : somethingElse" in currentImageFadeOut [14:57] I try [14:57] Cimi, I'm not *sure* that will work, but you can try [14:58] Cimi, otherwise you could create that animation dynamically and destroy it on realCrossFadeChanged [14:58] Saviq, hm, the api has both ids and canned queries, so i think the plugin will expose just the ids [14:58] Cimi, but not sure that'd really be that much better [14:58] mhr3, ah so you'd handle queries down there? [14:58] Saviq, I might be able to change the property affected [14:58] Saviq, yep [14:59] or change target [14:59] Cimi, that was what you called "hack" just a second ago ;) [14:59] yeah but who cares :D [14:59] unless we have better idea [14:59] Cimi, apparently you do :D [14:59] haha [14:59] Cimi, the only "better" idea was to move the animation outside of the parallel [14:59] yeah [14:59] Cimi, so that it doesn't get ran at all [15:00] Saviq, I could have two animations running [15:00] and call what I want [15:00] mhr3, so we don't need runQuery, it will just be "close" basically [15:00] not sure which is better [15:00] mhr3, ah, leaf nodes [15:00] Saviq, we still need activateDepartment() [15:01] which is pretty much runQuery() [15:01] mhr3, yeah, renamed [15:01] mhr3, made it gotoDepartment(string id), k? [15:01] i'm still wondering how that one could be merged with getDepartmentModel() [15:02] mhr3, well, in theory I could getDepartment() and close [15:02] i mean gotoDepartment could return new DepartmentModel [15:02] mhr3, scary [15:03] mhr3, I'd rather you departmentChanged [15:03] Saviq, well cause right now you're expected to do getDepartmentModel(foo); gotoDepartment(foo) [15:03] mhr3, hmm as long as ids are static [15:04] feels wrong [15:04] but if getDepModel is gone, i'm not sure how to the initial query for departments [15:04] mhr3, not really === jono is now known as Guest91026 [15:04] mhr3, I do gotoDep(foo); closeUI() [15:05] mhr3, you then do depChanged() → I do getDep() [15:05] Saviq, what if it's a hasChildren node? [15:05] mhr3, same [15:05] mhr3, ah you mean when you press "all foo"? [15:05] but you shouldn't close the dep ui when navigating [15:05] at least that's what mike said as some point [15:05] mhr3, yeah, I'd only close when it's a leaf node [15:06] right [15:06] mhr3, well, I'd close on press on "All foo" *or* leaf node *or* the top button [15:06] mhr3, on leaf node I'd *also* do gotoDep() [15:07] Saviq, i'm not sure about the gotoDep() -> depChanged() -> getDep() [15:07] i was thinking getDep() -> gotoDep() [15:07] cause the first one will take long [15:07] but why would I getDep [15:07] mhr3, I wouldn't need gotoDep() then [15:08] mhr3, since getDep() would already give me everything [15:08] Saviq, cause you can get the subtree right away and it will be filled [15:08] mhr3, gotoDep() would at that point equal closeUI [15:08] mhr3, since you'd already have loaded results for it [15:08] because of getDep() [15:09] mhr3, the only problem I see with that is [15:09] mhr3, when I go getDep(), you query the scope [15:09] no [15:09] yes? [15:09] mhr3, you want me to gotoDep() on _every_ dep change? why? [15:10] no, i'll just snapshot what i know about the dep tree at that point [15:10]