=== rickspencer3 is now known as rickspencer3-afk === jono_ is now known as jono [04:57] hyperair@ipwn:~$ ps -C notify-osd -o rsz=,command= [04:57] 194248 /usr/lib/notify-osd/notify-osd [04:57] win! [04:57] 194M of memory for a notification daemon that shows pretty notifications. [04:58] someone please tell me what about this is not right? [04:58] * hyperair kills notify-osd [04:59] hyperair: 16m here [04:59] well yeah. that's how it is when it starts [05:00] leave it a while and you get something like this [05:01] oh 194. I saw 19. [05:01] I was like "what's the big deal" [07:06] notify-osd uses 3m here ;) [08:24] DanRabbit: ping === mpt_ is now known as mpt [09:23] DBO, trying your branch now [09:24] DBO, the conditional cairo_destroy()s are embarrassing [09:25] DBO, no idea under by which drugs I was influenced there [13:35] * MacSlow -> lunch === MacSlow is now known as MacSlow|lunch [14:29] I can't find any documentation for python-indicate or information on the API changes between 0.1 and 0.2. Do they exist at all? [14:31] qense: There isn't a migration guide or anything. [14:31] ok [14:31] qense: The big thing that isn't is that there isn't an IndicateIndicatorMessage [14:31] object [14:31] ok [14:32] There are some new properties that are recognized, and they're all listed in the spec: https://wiki.ubuntu.com/MessagingMenu [14:33] That page will be a tremendous help. Thanks! === MacSlow|lunch is now known as MacSlow [14:40] MacSlow, got me emails? === chaotic_ is now known as chaotic [14:41] DBO, yes [14:41] did you check out me findings about the stack [14:41] did some tests [14:42] there's no difference between your branch and trunk yet [14:43] did two type of test [14:43] no the changes I made are correctness [14:43] you are supposed to free those windwos, and the conditional freeing was odd but not freeing a nil i snot required [14:43] 100 notifications with a pause of 12 secs [14:44] yeah? [14:45] and 50 notifications without pause... wait 600 secs to let queue empty and another 50 [14:45] yeah? [14:46] leak-footprint is nearly identical [14:46] are you using valgrind? [14:46] 3.0 MBytes with 12 secs pauses [14:46] 26 MBytes with the 50 & 50 test [14:46] not yet [14:46] under valgrind [14:47] i am not seeing any leaks when I just run the damn thing and send notifications [14:47] I ran into a nasty unrelated bug on my nvidia-box with notify-osd and dual-LCD [14:47] but seen these leaks in e.g. pango_cairo_show_layout() [14:48] i dont believe those to be the leaks... [14:48] it just doesn't seem to add up [14:48] and I know valgrind to be imperfect [14:49] I think those were listed as "still reachable" [14:49] nasty nevertheless [14:50] yeah [15:02] MacSlow, for whatever reason I still only get the memory leak when I hit the stack [15:04] MacSlow, I dont think 12 seconds is enough maybe [15:04] I am going every 30 seconds [15:05] 12 shoudlbe enough... an async. bubble is on-screen for 10 sec + 700ms (fade-in and out) [15:06] DBO, so the queue should always carry one notification max at any time [15:06] DBO, use... [15:07] index=1; while (($index<=100)); do notify-send "The Band" "Some Song ($index)" -i totem; echo Spawned bubble $index; sleep 30; index=$((index+1)); done [15:07] i am just trying to watch memory usage with some break points added in "Press enter to continue" kind of breakpoints to bisect down when the memory leak comes in [15:08] im seriously still seeing that memory leak only hits hard once we get queued up [15:08] there is a minor leak for every new icon displayed [15:08] but its like 12 bytes [15:08] there are a lot of small leaks like that in glib/gtk+ [15:09] DBO, I'm on a conf-call atm... so I'm not really fully following here [15:09] oh okay [15:13] MacSlow, when you can, walk me through how the queuing is done [15:13] its a bit dense [15:14] after the call [15:14] sure [15:54] * DBO looks at MacSlow [15:55] still on the call :( [15:55] DBO, just closed [15:55] DBO, ok... let's turn to class Stack [15:55] okay so lets talk the queue, which looks to be stack.c no [15:55] oh first let me say this [15:55] I just confirmed with another dev, the leak does not happen for them lest they let the notifications stack up [15:56] DBO, yeah... the "queue/list" lives in class Stack [15:56] so Im not nuts :P [15:56] lest? [15:56] lest == unless [15:57] DBO, that's what I also verified with my tests [15:57] sweet [15:57] so we are all on the same page [15:57] so now we gotta smack up this stack [15:57] and make it stop leaking [15:57] DBO, I once mined stack.c/display.c and bubble.c with printf()s showing me the ref-counts of all use objects [15:58] from that I'm cretain that everything is properly *_dispose()ed [15:59] I'll go also your branch so were talking about the same sources [16:00] well lets just work from the observation that someone getting multiple notifications queued up results in memory issues [16:00] DBO, did you valgrind a single notification "against" multiple yet? [16:01] nope, why? [16:01] valgrind is likely to point "closer to the culprint" than gdb can [16:01] DBO, or do you want go "line-by-line"? [16:01] just asking [16:02] I want to go functionally [16:02] ok [16:02] so when a notification is sent by notify-send [16:02] it goes through libnotify -> notify-osd -> dbus.c? [16:03] it comes via dbus and first lands in stack_notify_handler() stack.c [16:04] okay [16:04] DBO, see stack-glue.h where the handlers from stack.c get hooked up to dbus [16:04] ok see it [16:04] DBO, I don't think we need to touch that [16:04] nope [16:06] okay [16:06] so we are in stack_notify_handler [16:06] we have items in our queue [16:06] not yet [16:06] I assume a fresh start [16:07] so stack.c:584 gets skiped [16:08] stack.c:601 also gets skipped (as we assume we get a action-less notification) [16:08] DBO, or do you want to lead through stack_notify_handler() asking as question arise? [16:08] DBO, what ever you prefer [16:09] I am interested int stack_layout now [16:10] ok... [16:10] stack_layout() if called walks the queue for the next notification to show [16:11] checking if e.g. notifications should be suppressed [16:11] there is a method to my madness, if we were sitting next to each other this would be much easier [16:11] and then sees where to place a bubble [16:11] DBO, I second that [16:11] stack_layout gets called if only one bubble has been sent, correct? [16:11] yes [16:12] a timed out bubble "triggers" it or a new notification coming in [16:12] stack_next_to_display [16:12] stack_select_next_to_display [16:12] lets look there [16:13] how do I send a syncronous notification? [16:13] that grabs anything from the top of the queue [16:13] via a string-hint [16:14] e.g. notify-send "Volume" -i notification-audio-volume-medium -h int:value:75 -h string:x-canonical-private-synchronous: [16:14] ah [16:14] -h introduces a hint [16:15] how does a bubble get removed from this list? [16:15] then a "triplet" tells what type of hint, name and value [16:15] i see the ability to select the bubble, but where does it get removed from the list [16:16] DBO, ocne it times out (fade-out animation finishes) it gets unref'ed [16:16] that doesn't remove it from the list... [16:16] stack.c:251 [16:16] it's a GWeakNotify callback [16:16] oh there [16:16] that kicks it from the list [16:16] okay [16:21] MacSlow, is my cursory glance that there isn't really much code that doesn't get executed when there is only one bubble somewhat accurate? [16:22] double negation?! :) [16:23] there isn't much code that gets executed only when there are multiple items in the queue [16:23] yeah [16:24] the queue is filled up until 50 notifications are in queue [16:24] and one at a time is displayed [16:25] as one notification fades out it gets removed from the queue [16:25] * DBO wonders why getting more than depth == 1 has such hard fail [16:25] * MacSlow does too [16:25] the logic seems sound... [16:25] otherwise we'd be jumping at the bug right away :) [16:26] gee I've this bug again [16:26] F**K! [16:28] ? [16:29] icons missing... leading to "no layout"-errors... causing failing rendering [16:30] that stated with the extraction of the notify-osd icons from the themes into a separate package [16:30] brb [16:30] speaking of line 256 of stack.c [16:30] damnit! [16:30] get back here! [16:30] tedg: do you also think the indicator messages icon should have something extra? to denote new? [16:31] mac_v: Yeah, I do... [16:31] hehe ;p [16:32] hmm, i think djsiegel or DanRabbit decided not to have an icon change [16:33] but just to make it highlight [16:33] mac_v: the envelope gets bolder [16:33] but the panel icons for humanity are going to be changed abit [16:33] they are too light [16:34] djsiegel: yeah, i know but > bug #392265 , do you want an extra emblem of sot? [16:34] Launchpad bug 392265 in humanity-icon-theme "Indicator-applet icon for "new message" is too visually similar too the default icon" [Undecided,Confirmed] https://launchpad.net/bugs/392265 [16:35] mac_v: I do think they are too similar [16:35] but I don't know if an emblem is a good way to go [16:35] maybe a the envelope could fill, become solid white [16:35] err, solid gray/black [16:35] hmm , yeah something of the sort [16:35] i'm working on that atm [16:36] djsiegel: there is a problem , if we make it darker then the icons will not be visible in dark panels i.e.>UNR , so what we can do is , split *only* the panel icons into a separate theme , which will be a very small package and name it Humanity_dark or whatever , [16:37] make it inherit the rest of the humanity icons and all will be happy [16:37] humanity needs a dim bluetooth panel icon too, fwiw [16:38] njpatel: the bluetooth icon will be used in the panel :( [16:38] DBO, still messed up here [16:38] god I hate that [16:38] MacSlow, whats messed up? [16:38] oops menu* [16:38] DBO, starting notify-osd from the shell [16:38] mac_v: Oh I see [16:38] mac_v: that sucks [16:38] "(notify-osd:15598): Wnck-CRITICAL **: wnck_window_get_window_type: assertion `WNCK_IS_WINDOW (window)' failed" [16:38] at least the icon shows again [16:38] njpatel: DBO says he can hack the notification area to desaturate the icons similar to the UNR inactive window list [16:39] that will solve all the inconsistency problems [16:39] MacSlow, oh yeah, I saw that... [16:39] mac_v: that would be a most useful trick [16:39] I was wondering what causes those errors [16:39] DBO, I'm not getting them on intel [16:39] njpatel: you guys need to assign it => DBO [16:39] njpatel, common you were the guy who wrote AWN, remember all those swanky effects you did to xembed things. This is just desat :P [16:40] MacSlow, get them here [16:40] mac_v: it may be a bit late for karmic, but it's worth investigating [16:40] nevermind... just got them on intel too [16:40] DBO: those days are long gone, I'm in awe of you kids now...with your client side windows [16:40] it's from that dnd.c code [16:41] njpatel, you've them too [16:41] njpatel, notification area is all xembed still isn't it? [16:41] "xembed" *spew³* [16:41] :) [16:41] njpatel: there are complaints about the inconsistencies , this should fix it , we could do a FFE [16:41] DBO: lol, yes. was just saying :) [16:42] * MacSlow want to have FFE as his second forename [16:42] yeah, my logic to "yes this is possible" was largely "I have a slight idea how to do it and have seen AWN do much more impressive things to an xembed" [16:42] mac_v: it would be good, make a bug against gnome-panel + post to ayatana? Would give the weekend for people to consider it... [16:43] njpatel: lool already has asked the UX team , they just havent responded yet :( [16:43] mac_v, it "just" a few grey lines... how hard can it be [16:43] I pinged them again today [16:43] mac_v: hence I'm thinking ayatana-list....make a little noise if you know what I mean ;-) [16:43] * MacSlow crouches from the DUX-crowd [16:44] MacSlow, want help with them wnck errors? [16:44] DBO, I'd prefer bullet ;) [16:44] * mac_v thinks njpatel / lool making the noise would be better heard ;) [16:44] bang [16:44] mac_v, you're probably right [16:44] mac_v: I would back up your initial noise, don't have time to make noise myself at the moment :D [16:45] * mac_v ok , going to yell at the list right -> now [16:45] DBO, now... I also get the "no icon/no layout defined"-error with your branch on intel [16:46] make that two or thirty bullets [16:46] not my fault [16:46] i didn't touch the wnck codies [16:46] err, why is there a heart icon inside my nm-applet [16:46] it loves you [16:46] DBO, nothing in your patches looks like it indeed [16:47] and all worked yesterday with 0.9.22 / trunk [16:47] well the word also tells me you get this on your branch? [16:47] my ethernet connection loves me... [16:47] DBO, I need to go to the capoeira-classes... back in about 2 hours [16:47] njpatel, just make sure to keep your love secret from your switch. It's a bit of a whore [16:48] DBO, any questions you have until them... stuff 'em in an email and send it over [16:48] MacSlow, answer my question first damnit :P [16:48] do the issues happen in your branch too? [16:48] DBO, regarding the libwnk assertion... sure... go for it [16:48] * DBO murders MacSlow [16:48] DBO, yes in your branch and in trunk [16:48] okay :) [16:48] thats what I needed to know [16:48] it I will work on it [16:49] * MacSlow rejoins the fun in ~2h [16:49] * DBO has a math test in ~1h [16:49] I really shouldn't go because I have the flu === MacSlow is now known as MacSlow|capoeira [16:49] yet oddly I place my grade above the wellbeing of my classmates [16:50] hehe [16:50] http://people.canonical.com/~njpatel/network-love.png [16:52] * DBO notes there has not been a code commit to trunk since the 0.9.22 release [16:52] njpatel, thats badass [17:05] mac_v: around now [17:06] yup [17:06] mac_v: We're speaking of the ubuntuone icon is colourful bug, right? [17:06] mac_v: So we discussed in the release meeting and considered that the safest to implement is the icon theme change to use colour icons [17:06] lool: that one and all icons in general which use the notification area [17:07] mac_v: We're still blocked on UX response; I mailed ivanka [17:07] mac_v: Yes, but the icons in other packages are historically with colours [17:07] lool: why revert when a fix is available? [17:07] mac_v: What's the fix? [17:08] lool: DBO says we can tweak out the notification area similar to the window list to desaturate the icons [17:08] mac_v: It's a proposed change [17:08] mac_v: But it's not developed [17:08] mac_v: People had concerns that it was too late for code changes like these [17:09] we already do it in the window list :( why not give it a try first [17:09] mac_v: My only _personal_ concern for doing that is that it's unlikely that we can distinguish all icons very well if they are desaturated; think of red / orange / green warnings etc. [17:09] its not developed because nobody asked me to develop it :P [17:09] mac_v: Because we dont have the time, artwork deadline was yesterday [17:09] mac_v: It's not impossible to implement, it's just a) not decided we want that (design team) b) late and risky [17:09] lool: DBO has been willing to fix it , only no one has asked him to [17:10] mac_v: I know [17:10] oh... ok [17:10] mac_v: It might be that the design team says we should do it [17:10] mac_v: So what I'd like to ask you folks is to prepare a branch of humanity where we revert to colour icons [17:11] djsiegel: ^ ? [17:11] DBO: If you'd like to propose a patch to implement that feature, that's welcome; we should spend our development resources on fixing crashers at this point though [17:11] DBO: (Not my call ultimately of course) [17:11] or mine [17:12] it makes little difference to when it gets done now [17:12] we cant possible ship it with karmic [17:12] DBO: Well it's not impossible; there were reactions against following this track, but the design team wasn't there to comment [17:13] DBO: I hope the design team will agree with release team / desktop manager / others saying that it's too late to push more code changes now [17:13] * DBO wishes he could be involved with these discussions [17:13] DBO: The conclusion of the release meeting is the status quo except that we want to prepare the colour icons just in case [17:13] DBO: Anybody is welcome as long as the meeting remains productive [17:13] lool DBO mac_v, if we just pull humanity's panel icons, it will fall back on GNOME, etc. [17:14] or we can just put human panel icons back in [17:14] aaaaaaaaaanyhow [17:14] I am going to get ready for class [17:14] math test [17:14] spreading disease [17:14] its going to be a blast [17:14] mac_v: I'll keep you updated on the answer of design team [17:15] lool: ok [17:15] mac_v: Would you ming preparing that humanity branch for me in case we go that route? This is to speedup merging the change when that's decided [17:15] (and if that's decided of course) [17:16] lool: its no a big deal , once the decision is made we could just yank the icons and be done in 15mins ;) [17:19] mac_v: I thought you had a colourful version of these icons as well [17:20] mac_v: Or was this only for the categories? [17:21] lool: we dont have a color version of these *exact* icons , but had color version in a different style , that the deisgn team did not like *at all* , hence these icons... we might as well remove the panel icons and let the gnome icons be used [17:21] mac_v: Okay [17:21] mac_v: Or the human ones? [17:22] either way :) [17:56] lool: ping [17:57] being that the artwork deadline has passed.. does that mean gdm is going to stay as-is? [17:58] anyone? [18:04] DanRabbit: pong [18:05] mac_v, DanRabbit, lool [18:05] can we talk here? [18:05] I am having three separate PMs [18:05] okay okay [18:05] So [18:06] Here's the exact root of the problem we are facing [18:06] you guys have any ideas about my question? [18:06] The panel uses the same icons as the rest of the UI [18:06] djsiegel: as i said , this is a patch which dbo has already done for UNR [18:06] And no matter how we draw the icons in the panel, light or dark or purple or whatever [18:06] we can never do a monochrome icon without affecting the rest of the UI [18:07] but he had written it for the window list , all that needs to be done is assign it to him and he can come up with the patch [18:07] So, what we need is to tell the panel to use different icons than the rest of the UI [18:07] Are we speaking of the notification area or the panel? [18:07] lool yes [18:07] The only thing I am in a position to nod at is changes to art files [18:07] notification area [18:07] Q: foo or bar? A: yes [18:08] and applets [18:08] Ok thanks :) [18:08] if need be [18:08] patching applet sounds like a really bad idea [18:08] it's just too late [18:08] we're not changing any functionality [18:08] djsiegel: it is already done for the window list , and it was done by DBO [18:08] you guys aren't hearing me [18:08] it'll literally be this much change: [18:09] if gcc has to run again, I think it is too late [18:09] "I get my icon from network-stuff.svg" "Now I get my icon from network-stuff-panel.svg" [18:09] djsiegel: we had been mentioning this since sunday! the UX hasnt responded [18:09] mac_v: this is the first I have heard about it [18:09] lool: has been pinging ivanka and hasnt ot a response :( [18:09] I myself have been saying it since before we switched to monochrome icons [18:09] DanRabbit: That would break other themes [18:10] no, because of icon fallback [18:10] djsiegel: lool has been pinging ivanka and hasnt a response :( [18:10] ;) [18:10] I love the idea, but it's too late [18:10] mac_v: It's ok, we will get a reply at some point [18:10] too many changes to too many different code bases [18:10] let's do it for lucid [18:10] but, we have problems to solve in karmic [18:10] then, we must remove monochrome icons in Karmic [18:10] or it'll be broken [18:10] yeah [18:10] lool: but now you guys are saying its frozen :( [18:10] ok, lool, what do you suggest? [18:11] lool: we need to drop humanity panel icons [18:11] what is the branch you were proposing? [18:11] DanRabbit, mac_v: We're not going to do anything complex; I'm willing to consider the option of desaturaing notification area at runtime even if it's not my preferred one, but that will only get applied if design team wants it this way and desktop team is confortable with adding the patch that late [18:11] The current preferred change if any is to drop the B&W icons [18:11] mac_v, djsiegel, DanRabbit, lool: any ideas regarding if the gdm will be updated.. or if it is staying the same as now.. also i agree with going back to colored panel icons, they look better [18:11] The only other option is to keep what we have now [18:12] We don't even have to make a crazy patch like desaturating it! [18:12] djsiegel: pls read lool's response above , it can be done only if UX insists [18:12] lool: please check with desktop team if they are comfortable with the change this late [18:12] djsiegel: I'm asking to prepare the humanity changes to revert to the human or gnome icons for notification-area stuff [18:12] tell them UX is interested only if it looks like it isn't disruptive [18:12] Gnome would be best [18:12] Human icons are pretty unreadable on the UNR panel [18:12] djsiegel: Are you speaking for UX? I'd rather hear it from ivanka to whom I escalated [18:13] lool, I need a description of the problem still [18:13] who is worried about Humanity panel icons? [18:13] and why? [18:13] they icons look too light? That is what I heard [18:13] djsiegel: So you're picking this up from ivanka? [18:13] lool, yes [18:13] djsiegel: I'll forward you the emails then [18:13] ok, good [18:14] djsiegel: sent [18:15] djsiegel: the problem is : the panels use greyscale icons for the system icons , but the app icons are in color ... so lool and a few others feel that this is inconsistent behavior... IMO the system icons are greyscale and the rest are color[this is how win 7 does it too only the system icons are white , rest are color]... [18:15] djsiegel: We want to know whether the mix of black and white and coloured icons is acceptable for karmic, and what's the design team's preferred solution between all black and white, all colour, and mix of the two [18:16] djsiegel: if this is acceptable to keep using only the grey *system* icons for the panel , there is no problem *at all* ... its just that they are questioning the inconsistency [18:16] mac_v: It doens't compare [18:16] ok, I se [18:16] nothing needs to be done [18:17] mac_v: For instance rhythmox is shipped with Ubuntu desktop and UNR; should it be black and white? [18:17] mac_v: What about bluetooth? tomboy notes? [18:17] lool: as i said app icons are not allowed in the default icon theme [18:17] only generic icons [18:18] bluetooth is not a problem [18:18] no, we will never get all panel icons uniform as long as apps can put their own icons there [18:18] even if we monochrome them forcefully [18:18] djsiegel: i would say, we just draw a line and say , only system icons are greyscale .... and there is no confusion at all [18:19] no panel icon change [18:19] no code break [18:19] nothing needs to be done [18:21] my opinion on the matter.. is that eventually we will be going to gnome-shell.. ive run gnome-shell with both monochrome icons, and colored icons.. and i find that the colored ones look a whole lot better [18:22] lool: the bluetooth icon wasnt done , just because we were waiting for the decision... but either way... something needs to be decide [18:22] decided* [18:23] I'm happy I dont have to raise a lot of design or icon questions :-) [18:25] alright [18:25] djsiegel: lool: seriously... is there a problem if only the system icons are in greyscale? bluetooth will be done... and let the apps have color i dont see why this is considered inconsistent! [18:25] the thing I am concerned with is the humanity-style icons appearing in other interfaces [18:25] Ok, here is what I would like us to do. [18:27] * DanRabbit ---> bathroom [18:29] sjsiegel: if you guys decide to go with the monochrome icons.. itd be awesome if you included an alternate icon theme, either in the repos, or a tar.gz somewhere.. i really like the humanity theme, but if the monochrome icons stay, i think i'll have to switch back to gnome-colors [thumbs down] [18:30] [hate to sound like a broken record] [18:30] ok, that decides it, we are doing what natewiebe13 wants :~ [18:30] :) [18:30] djsiegel: as of now there is not much problem , of the humanity style icons appearing in the interfaces if we do only the system icons [18:30] mac_v: I just need to know of where this is happening [18:31] mac_v: if humanity panel icons are not appearing in other interfaces, I would like to keep humanity panel icons, but darken them a tad for the desktop [18:31] lool: ^ [18:31]