[07:29] didrocks, ping [07:31] pong Saviq [07:32] didrocks, first of all - I blame you :P how could we upload the whole new unity stack without ever bumping SONAME? :P [07:32] didrocks, now that we have that off our plate ;) [07:32] didrocks, http://packages.debian.org/source/experimental/zeroc-ice say we wanted that in ubuntu, what's the correct process? [07:33] Saviq: hum, you are talking about libunity or unity/nux? :p [07:33] didrocks, libunity [07:33] Saviq: for libunity, only the scope part is impacted (but yeah, unity8 as well I guess), bumping the soname once again makes rebuilding 40 components [07:33] Saviq: making the transition even harder :p [07:34] didrocks, ok, actually I meant libunity-core [07:34] people should start to know about ABI stability (especially when in 2 years, we went to 9 :p) [07:34] ;) [07:34] Saviq: ah, that's something else, I guess upstream forgot about it ;) [07:35] Saviq: on the ice version [07:35] Saviq: so, you are using that component? You know it's not in main [07:35] so not officially supported [07:35] didrocks, michi is about to use it [07:36] didrocks, the version in debian is 3.5b, 3.5 is already out [07:36] Saviq: right, doesn't mean it qualifies for main though :p [07:36] didrocks, yeah, I understand [07:36] didrocks, that's why I'm asking about the process (and if the answer is "just stay away from it", that's what it is...) [07:37] * libmcpp-dev binary and source package is in universe [07:37] * python-support binary and source package is in universe [07:37] * g++-4.6 binary and source package is in universe [07:37] * proguard binary and source package is in universe [07:37] * libjgoodies-forms-java binary and source package is in universe [07:37] * libjgoodies-looks-java binary and source package is in universe [07:37] python-support -> we can handle the transition, as for g++ [07:37] I'm more afraid about the others [07:37] those are the deps? [07:37] yeah, build-deps and deps [07:37] uh [07:38] and that would mean all this needs to be in main [07:38] which, maybe, pull other stuff in main [07:38] yeah [07:38] let's try the java part, juts for fun [07:38] * maven-debian-helper binary and source package is in universe [07:38] * libjgoodies-common-java binary and source package is in universe [07:38] * libmaven-javadoc-plugin-java binary and source package is in universe [07:38] ah maven… :p [07:38] (and that's only for libjgoodies-forms-java) [07:39] Saviq: without even seeing the code, I would gard against using it, and look if we can find an equivalent in main [07:40] didrocks, yeah, feels like it's too big a beast with some weird deps :/ [07:40] didrocks, here's michi__ ^ [07:40] Yep [07:40] Saviq: yeah, not really thrilled to get java in [07:40] hey michi__ [07:40] We don't need that. [07:40] michi__, I pasted you the discussion in PM [07:40] Only need the C++ sub-sections [07:40] michi__: well, the package build-dep on it [07:40] so we need it to build the package [07:41] You don't need Java to build Ice for C++ [07:41] michi__: right, but they are built from the same package [07:41] It's just that all the different Ice versions are bundled into a single source release [07:41] indeed [07:41] So you get Ice for Java, C++, C# etc. [07:41] and for having it in main [07:41] it means, you need to have all build-deps in main [07:41] Hmmm... [07:41] Basically, all I want is a ppa or some such that gets us Ice for C++. [07:41] I can build it from source, including one minor bug fix. [07:42] michi__: but then, you will use it, right? [07:42] But I don't know how to create a PPA and so on. [07:42] Use it to build unity-scopes-api, yes [07:42] and so, once we get unity 8 into distro and installed by default, it will need to be in main [07:42] Until the 3.5 packages are released. [07:42] which will get to that issue [07:42] I don't know what "need to be in main" means, sorry. [07:42] I'm totally ignorant about all the packaging stuff :( [07:42] michi__: you don't know ubuntu? :/ [07:43] there is main/universe [07:43] Nope :) [07:43] (restricted/multiverse) [07:43] Ah, OK. Yes, I know about that. [07:43] basically, ubuntu/canonical supports main and restricted [07:43] So, we can't do this? [07:43] meaning that packages in those pockets need to be supportable for us (contractually) [07:43] right [07:43] stuff that builds in main needs to be buildable with only components in main [07:43] This is for development on scopes only, for a limited period. [07:44] Yes, makes sense. [07:44] OK. [07:44] michi__: you mean that we won't need it in the end? [07:44] If I can't have it, that's really serious. [07:44] (like, in October) [07:44] No, I will need it eventually. [07:44] ok, so we need to ask this question now [07:45] because if we can't support it, the "put that in a ppa" won't fix it [07:45] and seeing what it is pulling, I have doubt [07:45] Could we take the 3.5b packages from here? http://packages.debian.org/source/experimental/zeroc-ice [07:45] michi__: again, this is *NOT* the pb [07:45] to update [07:45] the issue is with the source itself [07:45] Hmmm... [07:45] Ice 3.4 is in the normal repositories right now. [07:46] It's just that we can't use that version. [07:46] defines "normal" repositories [07:46] Sec... [07:46] tvoss: would be great that we do some kind of tutoring on how ubuntu work for PS techs btw ^ (not the first time I see that kind of questions ;)) [07:46] Yes, please! [07:46] Saviq: ok, i pushed a different showheader animation, i think it's what you wanted, if you can check [07:46] tsdgeos, cheers [07:47] Hmmm... [07:47] I just found Ice-3.5b with package manager. [07:47] It wasn't there a few days ago. [07:47] michi__, what didrocks is after [07:47] libzeroc-ice35b [07:47] michi__, is main vs. universe [07:48] michi__, main ubuntu repository is what goes into the .iso [07:48] didrocks, good idea. Do we have some slides available? Or even better: why don't we do a hangout on air, with a tutorial and some q&a? might be interesting to external folks, too [07:48] didrocks, thinking about xda and such [07:48] michi__, and that's what's officially supported - by us [07:48] Right. [07:48] michi__, so for unity-scopes-api, that will land in main ultimately [07:48] michi__, if ice is required [07:48] michi__, we need to bring ice into main [07:48] Yes, got that. [07:48] michi__, and all of it's build dependencies [07:48] tvoss: yeah, there is no real slides AFAIK, but we need to do it :) [07:48] Right. [07:48] or check for alternatives [07:49] if we can't support ice [07:49] michi__, because everything in main needs to build within main [07:49] And that means everything then, including Java, C#, Python, Objective-C, etc? [07:49] michi__: right, because they are all build-deps [07:49] or if we can separate the C++ part [07:49] yes, because you're including the _source_, not the binaries [07:49] we can do that as well [07:49] Can we put a butchered down source tree into main? [07:49] but yeah ^ [07:49] it really needs a good analyze [07:49] that's what I thought [07:49] that only contains C++? [07:49] we could try and have separate source packages [07:49] michi__: is the upstream source separated? [07:49] Yes [07:49] michi__, plus: everything that should go into main needs to be reviewed by security [07:50] I can hack up a butchered tree in an hour or so. [07:50] I'm quite familiar with that code :) [07:50] michi__, that's not maintainable ;D [07:50] michi__: hum, no, if it's not supported upstream, we can't really [07:50] on the long term [07:50] we need to pick upstream new versions [07:50] and upstream security fixes [07:50] Can we do something with RPMs? [07:50] ? [07:50] ZeroC publishes RPMs [07:50] no [07:50] Redhat packages [07:50] we build from sources in ubuntu [07:50] michi__: thanks, I know what a RPM is :) [07:50] :) [07:50] Sorry [07:51] :) [07:51] so, basically being in main means: [07:51] - having something we can maintain and provide support on [07:51] - being able to look at security issues and backport them promptly [07:51] didrocks, is there a wiki page for Ubuntu Engineering development practice? [07:51] - ensuring we don't duplicate with something that would work equally in main [07:52] tvoss: there are a lot of wiki page on how ubuntu is structured, but I guess that's too big for all UE upstream to digest [07:52] So, in effect, this means that we can use Ice I take it. [07:52] didrocks, yup, I was thinking about the executive summary [07:53] tvoss: not that I know of, maybe there is something that dholbach could point us at? [07:53] michi__: what does mean that? did you forget a "if"? [07:53] Yes. Rephrase: "Am I correct in my understanding that using Ice is not possible?" [07:54] michi__: no, we should really investigate properly [07:54] OK, what I can I do to help with that? [07:54] which means: what feature would you like to use from Ice? [07:54] do we already have an equivalent in main? [07:54] Not in main, I don't think. [07:54] How can I ask the bloody package manager to show where a package lives, main or universe? [07:54] michi__: you know that main used to build KDE. I think there are a lot of libraries :) [07:54] Properties doesn't seem to show it. [07:54] apt-cache policy [07:55] Thanks! [07:55] Sec. [07:55] saucy/universe [07:55] or saucy/main [07:55] Ice 3.4 for C++ is in raring/universe [07:55] I imagine it'll be in Saucy too. [07:56] That's libzeroc-ice34 [07:56] right [07:56] and libzeroc-ice34-dbg [07:56] yeah, so hence my question: [07:56] what do you use from ice that you don't find in other packages in main? [07:56] I'm not sure I get the question. [07:56] why you need Ice? [07:57] basically [07:57] It's middleware. [07:57] Does lots of smart things that will save a lot of work. [07:57] Like not having to hand-write marshaling and unmarshaling code, for example. [07:57] Process activation and deactivation. [07:57] load balancing. [07:57] on-demand loading of object implementations. [07:57] you name it. [07:58] I was looking at Ice because it would save us a fair amount of delopment time. [07:58] Hmmm... [07:58] About maintainability of a cut-down source tree. [07:58] The Ice source is organised like this: [07:58] ice/cpp [07:58] ice/java/ [07:59] ice/csharp [07:59] etc. [07:59] they should provide split tarballs ^, IMO [07:59] You can throw away all the top-level directories and only keep ice/cpp [07:59] and it'll work [07:59] Yes. [07:59] Saviq: +1 on that [07:59] For ZeroC, the debian packaging was never an issue because there is someone who did that as a volunteer. [08:00] michi__: mind opening the discussion with them? [08:00] I can try and talk to the Ice guys about this. [08:00] I do not like my chances though. [08:00] michi__: that would be great [08:00] It just means more work for them, for no gain for ZeroC. [08:00] I'll see how far I get. [08:00] michi__: basically, the requirements for having a package in main are at: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements [08:00] michi__, wtym, it'll get included and supported in Ubuntu main, that's gain for ZeroC :D [08:00] michi__: keep me posted please :) [08:00] Thanks! Will read that now. [08:00] Will do! [08:00] Saviq: yeah, meaning more debugging, more users [08:00] rotfl [08:01] :) [08:01] michi__, and it's easiest to do close to the source - they can just have a script that will split the tarball in parts [08:01] Yes. [08:01] michi__, we could do that, too, in theory, but that would be painful to maintain [08:02] OK, so if ZeroC puts up a tarball that contains only the C++ parts and builds, we'd be OK? [08:02] yeah, we avoid to fork the source tarballs for that reasons [08:02] Makes sense. [08:02] michi__: I'm looking at the code right now, to check quickly, but it seems ok for now [08:02] Doing it ourselves is probably no more work than writing rm -fr for a handful of directories. [08:02] michi__, once [08:02] I'll check with my former collegues [08:03] michi__, but then you need to maintain it [08:03] Yes, I know. [08:03] yeah, the one shot is easy [08:03] I hear you :) [08:03] maintenance is what the MIR asses :) [08:03] :) [08:03] MIR asses? I dont' get the joke [08:03] assess* [08:03] hehehe [08:04] Ah typos... [08:04] sil2100: I'll always blame my keyboard! [08:05] mzanetti: just to tell you, I managed to repro the crashing tests I've been fighting with and get a stacktrace. And thanks for your help [08:06] tvoss, I managed to break it [08:06] Saviq, ? [08:06] tvoss, sorry, tsdgeos [08:06] Saviq, :) [08:06] mzanetti: I used cgroups to limit the cpu allocated to the tests, figuring Jenkins was also running with lower available cpu than my local machine. [08:07] tsdgeos, when you make it so that the two section headers are close to each other [08:07] greyback: oh... interesting [08:08] tsdgeos, so: in Home, drag up so that "Frequent Apps" and "Favourite People" are on top of one another [08:08] tsdgeos, then swipe to the side [08:08] tsdgeos, the header comes down correctly [08:08] tsdgeos, but then drag down to reveal the apps [08:08] tsdgeos, they get confused and stuck to the top [08:10] tsdgeos, but yeah, the showHeader() anim is correct now - better than the original that got confused when the list was at the bottom [08:10] tsdgeos, easier to reproduce [08:10] tsdgeos, go to Apps, tap on SEARCH, drag [08:11] tsdgeos, actually: go to Apps, hide the page header, tap on SEARCH, drag [08:12] tsdgeos, it doesn't take the page header into account anymore [08:12] * tsdgeos tries [08:12] tsdgeos, but otherwise it's great :) [08:13] boooo [08:13] ok [08:13] need to fix that [08:16] paulliu, can you tackle https://bugs.launchpad.net/touch-preview-images/+bug/1190400 ? should be easy to fix [08:16] Launchpad bug 1190400 in touch-preview-images "[people-lens] segfault on saucy images" [High,Confirmed] [08:25] Saviq: ok [08:25] paulliu, thanks [08:46] Saviq, have a moment? [08:46] nic-doffay, hit me [08:47] Saviq, rotation is working well, however I'm having an issue with the slide out for the launcher. [08:48] I'm attempting to use a standalone property animation since I figured it doesn't need states and thus wouldn't need an additional Item wrapper around the launcher. [08:48] https://pastebin.canonical.com/92695/ [08:49] Saviq, check lines 134 & 529 [08:49] Nothing is happening. No output either. [08:50] (Unless if the animation is absent obv) [08:51] nic-doffay, that's probably because the launcher alread has states [08:51] Saviq: lp:~saviq/unity/8.fix-coding is conflicting [08:51] mzanetti, uh, fixing [08:52] nic-doffay, and they have precedence over any custom animation you use [08:52] nic-doffay, but actually [08:52] property PropertyAnimation animation: animation [08:52] whats wrong with the launcher? [08:52] mzanetti, nothing [08:52] nic-doffay, that binds the property to itself [08:53] nic-doffay, i.e. undefined [08:53] Saviq, I did try before with another different name. [08:53] How should I get around this issue? [08:54] nic-doffay, you need a different name, that's all [08:54] nic-doffay, but if you mean to get around the states issue [08:54] nic-doffay, first of all, make sure that the animation is actually running [08:57] Saviq, I have already, it apparently is. [08:57] Saviq, that was with the different name yesterday. [08:57] changed the name again now just to confirm. [09:00] mzanetti, q about Launcher.qml: 175 [09:01] mzanetti, why not Behavior.enabled: !(launcherDragArea.drag.active || dragArea.dragging) ? === alan_g is now known as alan_g|physio [09:02] hmm... there is a Behavior.enabled? interesting... must have missed that [09:02] mzanetti, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-behavior.html#enabled-prop [09:02] Saviq: I'll change it in my next MR [09:02] yep, found it [09:02] k [09:05] nic-doffay, so, I'd probably go about and add a new state [09:06] Saviq, in another parent item? [09:06] Saviq, or in the launcher itself? [09:06] nic-doffay, no, in Launcher.qml itself [09:06] Saviq, kk [09:06] nic-doffay, to hide "quickly" [09:06] mzanetti, one more q: Launcher.qml:232 [09:07] mzanetti, not sure I understand the comment [09:07] Saviq, I'd have to handle this in the onRotatedChange (unless I expose the rotating variable to Launcher.qml). [09:07] mzanetti, but I do know that "unnamed" state is problematic [09:07] This would override any binds. [09:08] Saviq: well, want this to be the default state. [09:08] mzanetti, there's no such thing as a default state [09:08] mzanetti, unnamed states will bite you in the a$$ [09:09] mzanetti, why can't it have a name? [09:09] because QML falls back to "" [09:09] mzanetti, ah wait, this way it might be fine [09:09] Saviq: one moment... searching for the right page in the docs [09:09] mzanetti, so you mean if no other states have when: true [09:10] mzanetti, then it falls back to the unnamed state [09:10] exactly [09:10] Saviq: from the docs: If the item is in its default state — that is, no explicit state has been set — then this property holds an empty string. Likewise, you can return an item to its default state by setting this property to an empty string. [09:10] http://qt-project.org/doc/qt-5.0/qtquick/qtquick-statesanimations-states.html#the-default-state [09:10] mzanetti, yeah, problem is what the default state is [09:11] mzanetti, i.e. if an animation changes some values, that becomes the default staet [09:11] mzanetti, not the "initial" one [09:11] mzanetti, but yeah, your use case is ifne [09:11] fine [09:12] mzanetti, what I mean is that the default state is modal [09:12] mzanetti, i.e. the default state is whatever the values were _when_ the state changed to non-default [09:12] mzanetti, so that can be tricky [09:12] Saviq: yep. and exactly thats the reason why I have that here... to make sure it actually reverts to being hidden [09:13] instead of staying to whatever x has been set [09:13] mzanetti, I'd probably go for explicit state name then [09:13] mzanetti, but yeah, that would require when:s everywhere [09:13] Saviq: yep... and quite tricky ones... I had that before [09:14] mzanetti, I'd probably go for a state: if/else... [09:14] mzanetti, but yeah, that then makes it tricky because you need additional properties to get where you want [09:15] nic-doffay, all in all, I'd go for another state [09:15] nic-doffay, and convert the Behavior on x in Launcher.qml [09:15] nic-doffay, to transitions: [ ] [09:15] hmm... yeah, that might do it... still this seems to work quite nicely... if you want me to change it I'll do... but I don't see the need right now tbh [09:15] Saviq: Argh.. people-lens -> libfolks -> gee-0.8 and people-lens -> unity -> gee-1.0.. [09:15] paulliu, right [09:15] Saviq, with the rotation variable exposed to the launcher? [09:15] and a when: [09:15] nic-doffay, sec [09:16] Saviq: I need to port libfolks first.. [09:16] paulliu, ignore, then, we're dropping the people lens this week [09:16] paulliu, at least temporarily [09:16] Saviq: ok [09:16] paulliu, please write on the bug what's the issue [09:16] paulliu, and return it to Confirmed [09:16] ok [09:17] nic-doffay, didn't you say that your only issue was hiding the launcher? [09:17] Saviq, yeah [09:17] nic-doffay, so yeah, just have State { name: "quickHide"; extends: "" } [09:18] * mzanetti needs to go buying some poison to get rid of lice on his strawberries :D [09:18] nic-doffay, and then a Transition { to: "quickHide" Sequentialanimation { NumberAnimation { duration: SnapDuration }; PropertyAction { target: launcher; property: "state", value: "" } } [09:18] or similar [09:19] mzanetti, lol lice? http://dictionary.cambridge.org/dictionary/british/louse [09:19] mzanetti, I hope you mean http://dictionary.cambridge.org/dictionary/british/aphid?q=aphids [09:22] mzanetti, maybe you have a different idea about temporarily changing the duration of the Launcher.x behaviour? [09:22] mzanetti, like a one-shot quick-hide [09:22] mzanetti, maybe something fits more with your other plans [09:23] nic-doffay, there's a bunch of different approaches you could take, like disabling the Behavior while a separate animation is running [09:23] nic-doffay, or the transitions [09:23] Saviq, I'm going to opt for the transitions. [09:23] nic-doffay, or changing the Behavior's duration temporarily [09:23] Shall I expose the rotation variable to the launcher? [09:24] or set the state from outside as I'm doing with the panel? [09:24] nic-doffay, no, nothing should know [09:24] nic-doffay, no of the shell parts should need to know that they got rotated [09:24] none [09:24] Saviq, as I thought, cool. [09:25] nic-doffay, there's a Launcher.switchToNextState(string state) method you should use [09:25] Saviq, I'll have a look. [09:37] * greyback moving to office, bbiab [09:42] Saviq, it's looking slick. [09:43] nic-doffay, cool [09:44] http://pastebin.ubuntu.com/5760874/ [09:44] erm [09:45] re [09:45] Saviq: yeah... the ones on plants ofc [09:45] Saviq, pushed. https://code.launchpad.net/~nicolas-doffay/unity/orientation/+merge/168100 [09:47] nic-doffay, conflict in Shell.qml [09:50] Saviq, cool sorting it. [09:57] Saviq, regarding... https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715 [09:59] MacSlow, pass the notification object to Notification.qml in Notifications.qml [09:59] Saviq, I've fixed the main issue (now using Notification's invokeAction() again), but want to ask if we can stick to "notificationRenderer" as I think naming it just "notifications" gets confusing becuase there's little difference in the naming of frontend and backend [09:59] MacSlow, let's go for "notificationList" maybe? [10:00] MacSlow, it's just a name, so... [10:00] Saviq, "notificationList" that' s ok too [10:00] larsu: ping [10:00] MacSlow, but do pass the notification object via a property to Notification.qml [10:00] MacSlow, instead of reaching back to the notificationList.model.get() [10:01] MacSlow, also, why get(id) and not get(index)? [10:01]