=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== salem_ is now known as _salem | ||
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 | 08:37 |
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:03 |
Saviq | mhr3, you won't be able to build u8 on trusty without new qt package names | 09:22 |
Saviq | mhr3, wth is "currentShellConfiguration"? ;) | 09:23 |
mhr3 | Saviq, i just want scopes, trusty u8 will have to be enough for now :) | 09:25 |
mhr3 | and it's whatever layout type your smart thing + user decided to use | 09:26 |
Saviq | mhr3, grep comes up empty ;), or is that in the API simply? | 09:28 |
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:29 |
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:30 |
mhr3 | or what they'll look like? | 09:31 |
mhr3 | will it be things like "touch-optimized" etc? | 09:31 |
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:34 |
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:35 |
mhr3 | but that'd be api break :P | 09:36 |
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:44 |
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:45 |
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:46 |
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:47 |
Saviq | seb128, bug #1320160 | 09:48 |
ubot5 | bug 1320160 in ubuntu-system-settings (Ubuntu) "Sorting by size in "storage" doesn't work" [Undecided,New] https://launchpad.net/bugs/1320160 | 09:48 |
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:50 |
Saviq | seb128, k | 09:52 |
Saviq | dednick, https://code.launchpad.net/~saviq/unity8/cmake-plugin-cleanup/+merge/218171 Approved → Needs Review for a reason? | 10:01 |
dednick | Saviq: i switched to Approved, but there's still alberts review pending. | 10:02 |
dednick | so i switched back | 10:02 |
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:03 | |
Saviq | it should be working this morning | 10:04 |
dednick | Saviq: couldnt be bothered. just approved it | 10:04 |
Saviq | ;) | 10:04 |
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:12 |
pete-woods | so you'll now need to create ~/.local/share/libusermetrics/sources/foo.json instead | 10:13 |
Cimi | pete-woods, thanks | 10:28 |
=== MacSlow is now known as MacSlow|lunch | ||
=== seb128_ is now known as seb128 | ||
mt_caret | Is anybody here? | 11:23 |
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:24 |
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:26 |
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:27 |
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:28 |
mt_caret | haven't tried that, I'll check... | 11:29 |
mt_caret | just tried it out, and it looks like i do get unity in the guest session | 11:34 |
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:35 |
Mirv | ok there was something wrong with my previous AP run, now UITK passed this time | 11:36 |
mt_caret_ | oh, and I also can't launch the terminal emulator after getting a launcher, it disappears in a flash | 11:42 |
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:48 |
Saviq | well, aborts, not crashes | 11:49 |
=== alan_g is now known as alan_g|lunch | ||
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:21 |
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:22 |
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:23 |
Saviq | mhr3, hint hint, I just did! ;D | 12:24 |
mhr3 | saviq, too subtle :) | 12:24 |
mzanetti | yes. too subtle | 12:24 |
mzanetti | no seriously... we're working on it... but we shouldn't land it before issues are fixed | 12:25 |
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:26 |
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:27 |
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:28 |
=== MacSlow|lunch is now known as MacSlow | ||
=== alan_g|lunch is now known as alan_g | ||
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
Saviq | mzanetti, if there are issues in the wiki, needs fixing - it indeed mentioned --arch= instead of --target=, which was your main issue | 12:40 |
mhr3 | saviq, could you maybe do a cross-building presentation in malta? | 12:41 |
mhr3 | demo* | 12:41 |
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:42 |
mzanetti | +1 | 12:43 |
Saviq | I'll see what I can do | 12:43 |
Saviq | greyback, we're ignoring the fact that you can see the old app when respawning for now? | 12:47 |
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:48 |
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:49 |
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:51 |
xnox | Saviq: ok. | 12:52 |
Saviq | xnox, awesome, thanks | 12:52 |
Saviq | looks like we could use click chroots indeed | 12:56 |
Saviq | greyback, hmm, app with --desktop_file_hint... Ctrl+C, app gets restarted, that expected? | 13:11 |
greyback | Saviq: no | 13:12 |
Saviq | greyback, this must be a fallout of the last fix :| | 13:12 |
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:14 |
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:15 |
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:16 |
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:17 |
* Saviq tries | 13:18 | |
=== ted is now known as tedg | ||
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:18 |
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:19 |
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:20 |
Saviq | greyback, maybe because they're focused? | 13:21 |
Saviq | greyback, I'll write down unexpected things on the MP | 13:22 |
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:23 |
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:24 |
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:25 |
Saviq | greyback, only have exceptions for known things - like QtWebProcess, signon-ui? | 13:26 |
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:27 |
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:28 |
greyback | Saviq: please add the strange behaviour you notice to the MR, I'll see what i can do | 13:30 |
Saviq | greyback, https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/524957 | 13:46 |
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:18 |
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:19 |
Saviq | mhr3, hmm hmm | 14:20 |
Saviq | mhr3, didn't request for departments require the canned query itself? | 14:21 |
mhr3 | Saviq, maybe... let's say that depId == cannedQuery | 14:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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 |
=== alan_g is now known as alan_g|tea | ||
mhr3 | yea.. no :) | 14:29 |
Saviq | mhr3, this just adds another property to be listened to Changed signals | 14:29 |
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:30 |
mhr3 | bools are good! | 14:31 |
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:32 |
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:33 |
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:34 |
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:35 |
Saviq | mhr3, bleh :| | 14:36 |
mzanetti | sil2100: yep. all good | 14:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
mhr3 | oh i missed the loaded prop | 14:43 |
Saviq | mhr3, yeah, status | 14:45 |
Saviq | mhr3, I'll modify the pad then | 14:46 |
Saviq | mhr3, to get on the same page | 14:46 |
mhr3 | ok, thx | 14:46 |
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:48 |
Saviq | mhr3, when now it'd just be a generic query fail | 14:49 |
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:50 |
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:51 |
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:52 |
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:53 |
Saviq | Cimi, so Number { parent: foo ? something : parallel } | 14:54 |
Saviq | Cimi, that should work I think | 14:54 |
Cimi | mmm | 14:54 |
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:55 |
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:57 |
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:58 |
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 | 14:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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 |
=== jono is now known as Guest91026 | ||
Saviq | mhr3, I do gotoDep(foo); closeUI() | 15:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:21 |
Saviq | oh oh, published already! :D | 15:22 |
mhr3 | then again, searchString isn't async | 15:22 |
Saviq | :| just unity-mir | 15:22 |
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:23 |
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:24 |
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:25 |
Saviq | mhr3, ok, the pad is good then, I think | 15:26 |
mhr3 | kk | 15:27 |
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:28 |
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:31 |
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:32 |
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:33 |
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:34 |
mhr3 | grr, so ditching this stupid wifi over the weekend | 15:36 |
mhr3 | hopefully i won't kill my laptop :) | 15:36 |
mhr3 | otherwise i'll consider it Cimi's fault :P | 15:37 |
=== gatox is now known as gatox_lunch | ||
paulliu | Saviq: ok | 15:53 |
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:55 |
paulliu | Saviq: ah.. ok | 15:56 |
Saviq | paulliu, so you can just run it with "/path/to/your/local/checkout lp:~paulliu/unity8/foo" | 15:56 |
=== tedg is now known as ted | ||
mhr3 | mhall119, ping? the 14.04 docs didn't get updated | 16:00 |
dandrader | mzanetti, since you're on the packaging etc | 16:04 |
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:05 |
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:06 |
greyback | dandrader: there's a qmake ".depends" command which can specify that one target requires another one | 16:07 |
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:09 |
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:11 |
mzanetti | and that's building with -j8 | 16:12 |
greyback | great | 16:12 |
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:13 |
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:14 |
dandrader | mzanetti, what about the changes from the "Getting it up and running" session? | 16:15 |
mzanetti | dandrader: right... still to be done | 16:15 |
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:16 |
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:17 |
* mzanetti doesn't know enough about what's changed, so doesn't argue in this case | 16:18 | |
mzanetti | greyback: but afaiu it won't even boot without that, no? | 16:19 |
greyback | mzanetti: it will | 16:19 |
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:20 |
mzanetti | got it | 16:21 |
greyback | ubuntuclient has a couple of small changes, which will probably make the experience better | 16:21 |
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:22 |
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:23 |
greyback | mzanetti: I've not tested my qtubuntu branch yet, so let's leave that decision until monday | 16:24 |
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:25 |
greyback | oh yeah | 16:26 |
dandrader | yes, reflashing got my rotation back \o/ (god knows what I f**ed up on the previous image) | 16:28 |
dandrader | greyback, whall I remove qpamirserver repo to avoid confusion? | 16:33 |
dandrader | shall | 16:33 |
greyback | dandrader: ok | 16:33 |
dandrader | will just bring your recent "Establish object ownership with more care" commit into qtmir and them nuke it | 16:35 |
greyback | dandrader: thanks! | 16:38 |
=== gatox_lunch is now known as gatox | ||
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:42 |
mhr3 | mhall119, just added afaik | 16:43 |
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:44 |
mhr3 | mhall119, +1 | 16:45 |
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:46 |
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:47 |
mhall119 | mhr3: once it's automated it'll only update the development version, not stable version | 16:51 |
mhr3 | mhall119, ok | 16:51 |
=== alan_g|tea is now known as alan_g | ||
=== dandrader is now known as dandrader|lunch | ||
=== alan_g is now known as alan_g|EOW | ||
mhall119 | mhr3: please verify http://developer.ubuntu.com/api/scopes/sdk-14.04/ | 17:05 |
mhr3 | it's ok | 17:06 |
mhall119 | thanks, let me know if there are any other changes you need | 17:06 |
* greyback eow o/ | 17:34 | |
=== _salem is now known as salem_ | ||
=== dandrader|lunch is now known as dandrader | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!