=== fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta [02:12] wow, it's so nice to work on a desktop package that takes less than 5 minutes to build :) [02:14] chrisccoulson: good evening :) [02:14] hi desrt, how are you? [02:14] pretty good [02:14] what package is that? [02:14] chrisccoulson: I can imagine. :) [02:14] desrt, gnome-terminal. i started building it and went off to get a drink, and it finished building before i even got out of the chair ;) [02:15] thank chpe, i guess :) [02:15] which is a lot quicker than building firefox ;) [02:15] is it using GSettings yet? [02:15] desrt, not the version we have ;) [02:15] oh you :p [02:44] robert_ancell, do you still have issues with your hard drive? [02:53] Could a core developer please retry https://edge.launchpad.net/ubuntu/+source/gtk+2.0/2.21.5-1ubuntu6/+build/1912973 ? [02:53] Looks like a temporary problem, and it blocks the webkit rebuild [02:54] or actually wait... [02:54] seems more complicated than that [02:55] whole chain of unmet build-dependencies on sparc [02:55] starting with glib === fta_ is now known as fta [02:56] well, sparc is in a very bad state anyway [02:56] https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.13-1ubuntu1 <-- apparently this wasn't even considered for building on sparc, any idea why? [02:57] it causes a whole chain of build failures: gdk-pixbuf, gtk+2.0, webkit and epiphany-browser [02:57] LucidFox: Forget sparc, its going to die. [02:57] Ah [02:58] I think glib is not built on sparc any more because there were just too many problems. [02:58] WHich breaks most other things, but meh. [02:58] Again, 99% sure the port is about to be removed/die. [02:58] yeah, i've not even bothered trying to get firefox to build on it anymore [02:58] chrisccoulson: Right, whenever I see a sparc FTBFs, I forget about it. [02:59] me too :) [03:00] techboard should be ruling on whether to kill it properly soon [03:00] * ajmitch will be glad to see it die :) [03:01] At UDS Maverick, a discussion was held about dropping sparc and ia64. If nobody was going to step up and maintain sparc, particularly toolchain, it would be dropped. Ia64 is not quite so badly off, but its not far from the same position, i.e for Maverick+1, if ia64 maintenance is not picked up, it dies too. [03:01] both are listed on the TB agenda for the next meeting [03:02] ajmitch: Oh really? Wow interesting. [03:02] yeah, it's one of the few wiki pages I'm still subscribed to :) [03:02] heh [03:03] nice - https://developer.mozilla.org/en/DOM/Touch_events [03:04] cool === fta_ is now known as fta [03:52] RAOF: around? === fta_ is now known as fta [04:57] micahg: Yes. [04:57] RAOF: hi, I'm merging gjs, should mozjs still be requires.private? [04:57] I believe this to be the case, yes. [04:58] Hasn't that got accepted upstream yet? [04:58] no [04:58] well, not that I can tell [04:58] no [04:59] It's not *necessary* if we're setting LD_LIBRARY_PATH all over the place, but it's still *correct* [04:59] micahg, sweet, one step closer to being able to build gnome-shell :) === fta_ is now known as fta [05:10] RAOF: do you remember the upstream bug for the JS private issue...i doubt they'll take it, but I can note it in the changelog [05:11] I didn't add it as a dep-3 tag to the patch? Bad RAOF. [05:12] https://bugzilla.gnome.org/show_bug.cgi?id=607627 [05:12] * micahg checks [05:12] Gnome bug 607627 in general "gjs-1.0.pc adds unnecessary libmozjs linkage to client apps" [Normal,Unconfirmed] [05:12] Thank you, ubot2 [05:15] RAOF: I didn't see a patch at all, but I'm making one now, thanks [05:15] Did I make the changes in the diff? Again, bad RAOF [05:16] I think so [05:21] * micahg thinks this is the most complicated merge yet [05:22] now if there's a debian version before the newest ubuntu version do I do -v from the older ubuntu version or latest ubuntu version [05:25] micahg: The most recent version in our archive. [05:25] RAOF: k, test building now, if it's good, I'm uploading and moving on :) [05:25] robert_ancell: BTW, I took Debian's mini soname bump [05:29] good morning [05:30] morning pitti, are you in a NEW mood this morning? [05:33] micahg: something particularly urgent? (we have archive admins every day) [05:34] no, not unless Feature freeze will hurt it [05:34] no, everything which is in NEW by today will be considered [05:34] * ajmitch likes hearing that [05:34] k, no rush then :) [05:49] RAOF: if I'm getting a warning, but it doesn't look valid because I examined the debs can I ignore it [05:49] What warning? [05:50] RAOF: http://pastebin.ubuntu.com/476759/ [05:51] oh, nm, it's normal since those vars aren't used in those pacakges [05:51] Are you sure the undefined ${gir:Depends} warning is benign? The unused variable warning is just fine, though. [05:51] * micahg will double check for that [05:56] RAOF: I see libgirepository1.0-1 as depends in the package, I don't know where that substitution is done [05:57] RAOF: debian has the same warning [06:03] micahg: Does gjs ship gobject introspeciton data (as opposed to consume it)? Does it have a call to dh_girepository? That's the debhelper tool which is supposed to generate gir:Depends [06:03] no call to that [06:05] and Debian doesn't have that either [06:05] Hey pitti. [06:08] micahg: Well, my call would be that one of the following is true: (1) gjs shouldn't have any ${gir:Depends} field, or (2) dh_girepository should be called during build. [06:09] RAOF: dh7 doesn't auto do that I"m guessing [06:09] You'd probably have to pass --with gir or somesuch, I'd bet. [06:10] * micahg could try and see what happens :) [06:13] won't let me prepare since it can''t call dh --with gir clean in LUcid [06:14] I'm not sure that “dh --with gir” is the right call, or even if there *is* a --with you could be using. [06:15] * micahg checks how long we've had it [06:18] RAOF: we've had it since 0.4, I don't think I should worry about it ATM [06:19] micahg: It's probably not too important. It's a packaging bug, though. [06:19] Does gjs actually ship any gobject-introspection data? [06:20] RAOF: I can file for debain [06:20] *debian [06:24] * micahg is uploading unless there are objections [06:31] going..going..gone :) === fta_ is now known as fta [06:58] Is anyone about? [06:59] !ask | gambs [06:59] !ask | gambs [06:59] gambs: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [06:59] micahg: "Aw, snap!" :) [06:59] pitti: heh, 1 second apart [07:01] Sorry-- Is it on purpose that the new Update Manager *disables* updates if it is unsure of your connection? (I'm not using network manager and it won't let me check for or run the updates I know I am able to get) [07:02] gambs: ah, that's a q for mvo, he's not online yet, though [07:02] I'd say it should check "ip route" for a default route instead of just NM [07:03] but anyway, we pretty much assume NM in Ubuntu [07:03] so without NM this is not really supported [07:03] Yes, understandable, but it warns me that it may not be able to get the updates AND takes the option away of even trying. [07:04] that's certainly a bit overzealous [07:05] RAOF: debian 592694 (gjs packaging bug) [07:05] Debian bug 592694 in gjs "libgjs0a has ${gir:Depends} but it's not substituted" [Minor,Open] http://bugs.debian.org/592694 [07:05] pitti: Is mvo likely to show up soon? It is 2 AM in my timezone. [07:10] * robert_ancell hates projects that don't have a proper website, tarball location, or any real information as to where the source is and how to find the latest changes [07:11] pitti: unfortunately that raises a whole class of new bugs there [07:11] robert_ancell: should I grab the new gnome-shell from experimental and upload? [07:12] micahg, if it compiles, go for it! [07:14] robert_ancell: What project are you referring to in particular? [07:14] TheMuso, libv4l [07:14] but there are a lot of other projects that do it too.. [07:18] ah [07:19] robert_ancell: I happen to agree re projects not having easy to find tarballs/site/info/changes. [07:37] good morning [07:38] gambs: yes, he should [07:39] ajmitch: "that" is? [07:39] robert_ancell: didn't work OOTB, .la issues [07:40] micahg, gnome-shell? [07:41] robert_ancell: yeah, does gnome-shell have a freeze exception like the rest of gnome or is that main only? [07:43] micahg, I would assume so, pitti? Either way, it's mostly experimental still [07:44] I'm inclined to say that seb128 will approve it [07:44] k, so maybe I"ll leave this for next week [07:44] so I think we should go on with updates to it for some time still [07:45] pitti: I'm happy to keep it updated as long as the release team will let me :) [07:46] no objections from my side [07:47] alrighty then :) [07:54] robert_ancell: /usr/share/gir-1.0/PangoCairo-1.0.gir: Incompatible version 1.0 (supported: 1.1) [07:55] micahg, you need to update, mine is 1.1 [07:55] update gir-repository-dev? [07:55] libpango1.0-dev [07:55] oh [07:55] * micahg checks [07:55] I have 1.28.1-1ubuntu3 [07:56] ah, I guess I need an apt-get update :) [07:56] s/update/upgrade [07:56] pitti: hi , fix committed for Bug 616569 conflicts with bug 409338 [07:56] Launchpad bug 616569 in jockey (Ubuntu) (and 2 other projects) "hardware drivers shows window called untitle windows at scaning/download drivers (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/616569 [07:56] Launchpad bug 409338 in jockey (Ubuntu) (and 2 other projects) "Change the name of "Hardware drivers" (affects: 2) (heat: 33)" [Low,In progress] https://launchpad.net/bugs/409338 [08:12] robert_ancell: hi, any progress with gtk3 already? :) [08:12] slomo, hey, i'm just fixing a bug where it doesn't compile if builddir != srcdir [08:13] slomo, did debian use 011_immodule-cache-dir.patch before? [08:14] robert_ancell: yes, i dropped this for gtk3 though [08:14] you can take the gtk3 patches from svn, i've updated them all already [08:14] no need to do the same work twice ;) [08:14] the immodule-cache-dir patch can be dropped because upstream has a similar solution now [08:15] slomo, heh, I did them before you showed me svn yesterday! I've merged the debian changes over to the bzr branch I'm working on. There isn't anything worth sending back to you from this side yet though [08:16] slomo, have you had it building yet? I can build from git but haven't got dpkg happy yet [08:17] yes, it builds but the install step of debian/rules fails currently (the .install files have some errors) [08:17] nice [08:17] is the cheese performance problem gone btw? [08:18] as said, the remaining issues with gtk3 are the install files, copyright and a diversion for the update-icon-cache file ;) [08:21] slomo, still the same problem with cheese/gstreamer. I've been looking around but I don't know enough about gstreamer. Seems widely reported in Fedora and GNOME bugzillas though [08:21] the build problem I'm working on only affects introspection [08:23] can you give me the gnome/fedora bug urls? [08:24] morning mvo [08:24] mvo: thanks for the merge ;) [08:25] kiwinote: cheers, my pleasure. I'm very happy with the outcome now, I think there one or two fixmes left, but I think it now integrates very well into the code and the ui [08:26] mvo: hi , is the SC add-ons branch gonna make if for Maverick? [seeing that today is feature freeze :) ] [08:26] slomo, I've linked them off bug #610600 [08:26] Launchpad bug 610600 in cheese (Fedora) (and 5 other projects) "Serious video performance regression in cheese (2.28.1->2.30.1) (affects: 2) (heat: 16)" [Unknown,Unknown] https://launchpad.net/bugs/610600 [08:27] slomo, also, do you know where the official source of libv4l is? Fedora is running a 0.7 version which doesn't seem to have a tarball (the only major change I can see is ignoring the first frame if it is corrupt) [08:28] vish: its very tight, its >< this close [08:28] hehe! :D [08:29] beside the code one concern is that we need a clenaup action in the archive [08:29] to find out about the bogus suggests [08:29] when we did that with recommends it took quite a while to find and fix them [08:31] mvo: yeah , exactly! mpt mentioned that we can expect a lot of bugs due to wrong suggests.. so trying to be ready ;) [08:31] robert_ancell: no idea, sorry [08:31] vish: :) === DrPepperKid is now known as MacSlow [08:37] robert_ancell: no idea about the cheese bug, the bug reports are full of noise [08:38] slomo, yeah, I couldn't find anything concrete. Did the pipeline I put in the Ubuntu bug make sense? It looks like a v4l/gst issue to me [08:41] robert_ancell: well, you should add a queue between the v4l2src and the next element... should improve everything a bit [08:42] robert_ancell: and are you running with gst-plugins-good 0.10.24.2 or .3? [08:42] slomo, 0.10.24.2-1ubuntu1 [08:43] ok [08:44] robert_ancell: you should report a bug with your pipeline (+ queue) against gst-plugins-good in gnome bugzilla [08:45] slomo, ok, will do [08:45] robert_ancell: and the debug output you get if you set GST_DEBUG=v4l*:5,theora*:5,GST_QOS:5 before running that pipeline === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [09:00] morning [09:02] hey [09:02] lut huats [09:02] hey seb128 [09:02] hey pitti [09:02] hello seb128 and pitti === almaisan-away is now known as al-maisan === cypher_ is now known as czajkowski [09:10] * vish twiddles fingers.. lp locked down! [09:13] hrm, I can see that LP is down, but why does code.launchpad.net has to be down as well :/ [09:13] * mvo wants to merge branches [09:14] great timing they picked again for that... [09:14] it just feature freeze day [09:14] ;-) [09:15] we should get /extra time/ when they do that! :D [09:17] pitti: sorry, was responding to your statement about assuming NM is available, I'd been bitten by an annoying bug with U1 related to that :) [09:18] ah [09:20] code should not silently fail just because the interface is up but isn't being controlled by NM [09:27] james_w: is there a trick to convince bzr mu to do the first-ever import of an orig.tar.bz2? [09:27] james_w: it keeps telling me "bzr: ERROR: The target file system-config-date_1.9.60.orig.tar.bz2 already exists,..." [09:44] re [09:44] huats, lut [09:45] slomo, hi, the update from yesterday didn't fix the video recording issue... [09:45] the performance issue [10:04] mvo: I fixed the issues you mentionned in the review of my addons branch. Please re-check :) [10:06] devildante: many thanks, I will do as soon as launchpad is back [10:06] mvo: please re-check the tests, it's the first time I've written one and I don't know if I've done it well [10:07] mvo: should I ask mpt about the issue with the install button? [10:07] Good morning mvo, how's things [10:08] mpt: good morning. good [10:09] mpt: hi mpt :) [10:09] mpt: we are looking at the addons branch currently and there are two issues with the design I would like to get input on [10:09] see https://code.edge.launchpad.net/~ilidrissi.amine/software-center/addons/+merge/30946 [10:09] ok, I'll re-pull [10:11] bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ilidrissi.amine/software-center/addons/". [10:11] that's odd [10:11] launchpad is down [10:11] I think its a trick to ensure we don't work too hard on feature freeze day [10:11] mvo: but it's a read-only operation [10:11] mvo: :p [10:12] DOWN ;) [10:12] but yeah [10:12] mvo: does "software-center search:app that does something" seem good syntax for opening s-c with a searchterm preloaded? [10:12] I don't quite understand why checkouts are no longer possible [10:13] kiwinote: yes, I wonder if it would make sense to try to be compatible why the aptitude search synatax (at least a little bit) its pretty powerful [10:14] kiwinote: hm, maybe --search instead? [10:14] mvo: could do, although I thought that "software-center --search:apt apt:abiword" wouldn't make much sense.. [10:15] kiwinote: yeah, that is true [10:16] kiwinote: search:pattern is fine [10:16] is there a way to stop desktopcouch from filling my $HOME on nfs with useless logfiles? [10:18] kiwinote: I will check your other branches (especially the speed one) today too [10:19] mvo: just a few notes about the speed branch: [10:20] mvo: the sc-and-the-need-for-speed was very fast, but I have spent quite some time trying to get it up to date with trunk. I constantly seemed to get some quite random regressions. [10:21] kiwinote: I think you'll have some problems when my addons branch gets merged, since it's not snappy [10:21] mvo: so I started work on the startup-speed branch which is not at all as fast yet, but I'm basically applying the same sorts of changes on a fresh copy of trunk [10:22] devildante: I'll diagnose it once it lands ;) [10:22] kiwinote: yeah, I noticed that. I like the startup-speed one. the other one is super-fast, but a bit hard to follow [10:22] kiwinote: so this way I can merge it bit by bit [10:22] mvo: yeah, I'm doing nice neat commits now ;) [10:22] mvo: forgot to tell you that icons for add-ons are finally working :) [10:22] kiwinote: :) [10:23] devildante: sweet [10:23] devildante: how do you feel about navigation ? [10:23] devildante: to be able to get from the addon description to the page? [10:23] seb128: i talked with robert ancell about it already, he's going to file a useful bug without noise against gstreamer later ;) [10:24] mvo: that's a little slow [10:24] slomo, ok thanks [10:24] mvo: I think some tweaks will do the trick [10:24] mvo, you mean navigating to the screen for each individual add-on? [10:26] mpt: I thought he were talking about getting to the appdetailsview [10:26] mpt: maybe I didn't understand? [10:26] mpt: being able to get more info about the addon [10:26] yes [10:26] I haven't figured out a nice way to do that yet [10:27] I thought maybe an arrow button at the trailing end of each checkbox, but that would be zig-zaggy because the checkbox labels are different lengths [10:27] mpt: for now, I've added the pkgname near each add-on [10:28] mpt: maybe converting these to links that leads to their description will do the trick? [10:29] I'll have a look when Launchpad gets back, but I doubt it'll look good to show add-on package names [10:30] mpt: should I remove the pkgnames then? [10:30] I'll have a look when Launchpad gets back [10:31] http://www.flamingspork.com/blog/2010/05/08/desktop-couch-has-been-nothing-but-suck/ [10:31] amen [10:31] mpt: well, bilalakhtar on ubuntu-bugs is screaming that LP IS UP!! :p [10:31] ah, so it is [10:31] which is wrong [10:32] still getting connection refused errors there [10:32] seb128: but they have removed the message [10:33] me too [10:33] mpt: I like something that gives me a indication of the name (appname or pkgname) in the addon line but I can see that its a problem because the space is small [10:33] seconded [10:34] So, Launchpad isn't up enough for me to check out a branch, but it is up enough for me to have reported the bug about not being able to check out the branch [10:35] ok [10:35] now lp is up enough to do checkouts [10:36] you can resume work ;-) [10:36] oh yeah, IT'S WORKING!! :p [10:38] ooh! [10:38] its back [10:38] * pitti was desperately waiting, too [10:39] mpt: my other point is the install button moving down, with gimp and the default window size the button is entirely off the screen [10:40] mvo: I did that according to the software-center spec [10:41] Yes, that's my fault [10:41] I left that ambiguous [10:43] devildante: I know, this is why I wanted to talk to mpt about it [10:44] again, its a little bit tricky to find a good place as the addon list can be long(ish) [10:44] pitti, is there any reason bug #595096 is incomplete? [10:44] Launchpad bug 595096 in ubuntu-sso-client (Ubuntu) (and 1 other project) "[MIR] ubuntu-sso-client (affects: 1) (heat: 71)" [Undecided,Incomplete] https://launchpad.net/bugs/595096 [10:46] seb128: I don't think so; I set it back to new [10:46] pitti, thanks [10:47] devildante, your calculation of download + installed size is great, but it should be shown even for items that don't have any add-ons. Could you fix that while you're waiting for me to sort out the button placement? Show it in a row like the Version, License, and Updates are. [10:48] mpt: you mean, calculate download + install size for the application? [10:49] devildante, yes [10:49] mpt: okay, will do it now [10:49] devildante, search for the string "Text describing" in the spec [10:52] thanks [10:52] mpt: thank you ! :) [10:54] mpt: about the amount of space free, how will we do that? maybe the user has a /usr partition, and we're installing to both /etc and /usr (for example) [10:54] ergh, really? [10:55] Do we still know, ahead of time, whether there's enough free disk space? I.e. do we know how much more space will be taken up on /etc and on /usr? [10:56] mpt: I think we could know the total size [10:56] mpt: we just know how much we need on "/" [10:56] not how its distributed inside the deb [10:56] i.e. the kernel will need a lot in /boot [10:56] X a lot in /usr [10:56] something else only /sbin [10:57] etc [10:57] so for a system with multiple mounts its complicated [10:57] So knowing the installed size doesn't protect you from running out of disk space [10:57] correct, a common problem is /boot being too small [10:58] the upgrader tries very hard to guess based on estimates and patterns etc, but it does not always get it right too (but its pretty good at it) [11:00] fun [11:01] yep :/ [11:01] seb128, please merge this -> https://code.edge.launchpad.net/~rodrigo-moya/ubuntu/maverick/tomboy/fix-u1-note/+merge/32429 [11:01] the inperfect reality [11:01] devildante, I found a bug: 1. Navigate to Gimp, check/uncheck one of the add-ons. Now back up and navigate to any other software item. The item screen still contains "Cancel" and "Apply Changes" when you haven't made any changes, and even if that item has no add-ons at all. [11:01] rodrigo_, ok [11:01] rodrigo_, hey btw, how are you [11:01] seb128, fine, thanks [11:01] and you? [11:01] mpt: will check [11:02] rodrigo_, lot to do this week but I'm alright otherwise ;-) [11:02] seb128, yeah, very busy week, indeed :) [11:03] mpt: true [11:03] rodrigo_: are you a desktopcouch upstream dev? [11:04] tjaalton, not really, but I'm close, what's up? [11:04] rodrigo_: I'd like to be able to disable logging altogether [11:04] it's not nice on NFS etc [11:04] tjaalton, right [11:04] and we have 20000 users ;) [11:05] granted only some will use gwibber [11:05] but for instance my logfiles take 400MB [11:05] despite it rotating the logs [11:06] mpt: fixed in 2 lines of code :p [11:07] rodrigo_: I'd be happy to disable it locally by patching the current version in lucid, but a long-term solution would be nice [11:07] tjaalton, yes, if you have a patch, propose it for merging [11:08] tjaalton, a good way would be to have a command line argument, or a setting in the config file [11:08] devildante, ok, I think I've worked out a solution, but it will take me a wee while to sketch it out [11:09] mpt: okay [11:10] rodrigo_: I'll have a look, thanks [11:11] devildante, basically, instead of the "installed state bar" and the "availability state bar" that the spec talks about, there'll be an installed state bar that's always at the top (just below the icon + title + summary), and a separate add-ons state bar that appears only when you're changing add-ons for something that's already installed. [11:12] tjaalton, if you want to discuss further details, CardinalFang on #ubuntuone is an upstream developer [11:13] rodrigo_: ok, I might [11:13] well, should really [11:14] devildante, so, move the current bar back to the top. Then have a new bar that appears only when both (1) the main item is installed and (2) you've twiddled the checkboxes [11:15] Does that make sense? [11:16] mpt: yes [11:20] devildante: do you mind pushing the latest version of your branch? [11:21] kiwinote: lemme fix some little things and I'll push it :) [11:21] mpt, like this: http://i.imgur.com/XaRtS.png ? [11:21] devildante: sure, thanks [11:21] kiwinote: np :) [11:22] devildante, that's a start. :-) Now reverse the order of the buttons ( Cancel ) ( Apply Changes ) , capitalize "Changes", and add a background color the same as the installed state bar [11:23] mpt: okay [11:25] devildante, for the package names, what do you think about making them light grey and clickable? [11:32] vish: did you try removing the saved session? re: panel issue on unity [11:32] didrocks: i dint have any saved sessions to begin with [11:32] vish: ok, so this is a different issue [11:32] vish: not conflicting systray [11:33] yeah.. [11:33] mpt: I'll see [11:33] didrocks: we should probably split the bug? [11:33] vish: right [11:33] mpt: is this close to what you want: http://i.imgur.com/WXp0i.png [11:33] cool , [11:33] * vish files another bug === MacSlow is now known as MacSlow|lunch [11:36] mpt: Remove + Apply Changes , Cancel are all in the same page. but they are not all related.. info overloading.. :s why apply changes *and* cancel , could we just use it as as single button? "Install Addons" <-> "Remove Addons" depending on the changes , now it would probably we weird if we are installing some and removing at the same time.. hmm.. [11:37] *be weird [11:37] vish: cancel means reverting the changes before even applying them [11:38] devildante: got that , but the buttons in the same page are all not the same function , "Remove" is a separate entity from the changes below , in other prefs dialogues , Apply Changes , will mean applying changes to whatever we have done in the whole page [11:39] vish: what about "apply changes to add-ons" or "apply add-ons changes"? [11:40] vish, they'll be in different parts of the screen, immediately below the things they apply to. "Remove" will be immediately below the title and summary of the main item. "Cancel" and "Apply Changes" will be immediately below the add-ons section. [11:40] mpt: is the above image what you want? [11:40] ah, sorry, didn't see that one [11:41] seb128: eh, did something in gtk treeview change? gtk_tree_view_remove_column seems to take endless time (within the seconds range) [11:41] devildante, getting closer. :-) Now make "Total size:" a separate row, like "Version:" and "License:" are (but above the bar, not below it). Remember, size should be shown even when you haven't made any add-ons changes, and even when there are no add-ons at all. [11:42] mpt: right , but still they are in a single page which means the "Apply changes" doesnt control the "Remove" , from the current screenshot , it seems we have to Select "remove" and then "Apply Changes" [11:42] vish, nothing controls the "Remove". It's a button. [11:42] mpt: does total size also include add-ons size or only the main pkg? [11:43] devildante, both. [11:43] hence "total" [11:43] mpt: okay [11:43] thanks [11:44] mpt: but then, the "apply changes" bar shouldn't have a Total size label. What should we put there? [11:44] mpt: exactly! , it is not controlled by the "Apply changes" , which is what i'm trying to get at , we probably need to name the button below better. Now imagine what happens when someone is trying to add. "Install" will be separate from the addons , we need to make it a single action [11:45] devildante, the total price of any new add-ons you've selected. Usually that will be "Free". [11:45] mpt: okay [11:46] anyways.. /me goes on with filing a bug about unity ;) [11:46] vish, just hang tight for a few minutes until I've finished this sketch of the different situations. I think it'll be fine. [11:47] :) [11:47] oh god, that means more work for me :p [11:51] mvo, not that I know, did that start recently? [11:52] seb128: not sure, I have a workaround [11:52] seb128: off to lunch [11:52] mvo, enjoy [11:52] I'm just back from lunch [11:53] mvo: what is app_details.price equal to when the app is purchasable? [11:55] checkbox it! :D [11:56] oops! late comment! [11:56] vish: ??? [11:57] devildante: a string other than "" basicly [11:57] * mvo is really off for lunch now [11:57] mvo: okay, take your time :) [11:58] devildante: nah.. was about to say , instead of the "install/remove" button we can make it a checkbox , but mp-t is already working on it :) hit enter in the wrong window only now! [11:59] vish: a checkbox in this case sounds weird to me [11:59] vish: then again, I'm not a designer :p [11:59] devildante: mp-t in on it... no worry for us ;p [11:59] is* [11:59] vish: okay :) === zyga is now known as zyga-afk [12:20] seb128, since the 9th our armel omap4 images cant run oem-config anymore and it looks like thats caused by debus not being able to start, did you get any similar bugreports since your upload on monday ? [12:20] s/debus/dbus/ [12:20] ogra, no [12:21]