[09:43] anyone know where sense is these days? [10:34] klattimer: he has been here yesterday evening [10:34] kklimonda: cheers [10:34] need to get a hold of him, if you see him later will you let him know [10:34] klattimer: either send him an email or leave memo.. email is the best though [10:35] klattimer: I may not remember or miss him [10:35] k yeah, that's probably a better idea [10:36] number of workspaces in unity is 1 is that intended? [10:37] *default [10:39] om26er: it makes sense - most new users don't use virtual desktops at all. But I have no idea whether it's a design decision or some late bug :) [10:40] kklimonda, wouldnt that kill the purpose of a workspace switcher ? === MacSlow is now known as MacSlow|lunch [12:13] mpt: any idea on how to fix the bug? [12:14] yesterday I tried (1 sec, no more as was night :D) something like state = widget.get_state() [12:14] but it gives me something like gtk.STATE_NORMAL [12:14] always [12:18] Cimi: what are you trying to do? [12:19] https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/635208 klattimer [12:19] Launchpad bug 635208 in software-center (Ubuntu) "Unfocused selected item in software list is white on light grey (affected: 1, heat: 10)" [Low,Triaged] [12:21] Cimi: try checking the state of children and parents [12:21] see if they differ [12:21] ah hang on [12:21] mmm [12:22] you're using the cell's state for the colours? [12:22] parent [12:22] that's not going to work [12:22] yeah, you want to get the parent's state [12:22] klattimer: not me [12:22] :) [12:22] well, whoever [12:22] klattimer: it's software center, mpt just pointed me that bug [12:24] klattimer: widget.get_parent() is enough in python? [12:24] don't have the doc installed :D [12:24] off the top of my head, maybe [12:26] Cimi: just checked, yep [12:26] that'll do it [12:26] but doesn't seem to work :) [12:26] or parent is still problematic [12:26] :/ [12:27] well, I'd need to dig further in order to figure it out [12:27] that was just an off the top of my head thought [12:28] klattimer: maybe mpt or whoever wrote that code knows why he did the state in that way [12:28] maybe [12:28] (checking if the cell is selected) [12:28] I say I say [12:28] well, it looks like a custom cell renderer [12:28] Is someone accusing me of writing code? [12:28] ahaha [12:28] lol [12:28] no mpt :P [12:29] Cimi: check the blame log [12:29] That code is probably Matthew McGowan [12:31] mpt: is he subscribed to the bug? [12:31] no [12:31] mpt: now he is :P [12:43] kenvandine: can we close this bug https://bugs.launchpad.net/indicator-application/+bug/569273 [12:43] Launchpad bug 569273 in Application Indicators "memory leak in gnome-power-manager (affected: 60, heat: 319)" [Medium,In progress] [12:43] fix should have been released by now, and the remaining memory leaks are either deep in gslice or false positives === MacSlow|lunch is now known as MacSlow [14:44] hello friends... i just installed maverick on a friends laptop but notify-osd is not showing.. instead old notification are showing up.. notify-osd is already installed. [14:46] you need to kill the original notification daemon [14:46] then notify-osd should get start up automatically. [14:47] and that would be pkill notify-osd? [14:47] oh [14:47] sorry [14:48] the original one... [14:48] i mean what is the process name [14:53] thanks got it.. removed the notification-daemon package.. thanks [14:58] klattimer: kenvandine is wondering about vino [14:59] jcastro: what about it? [14:59] is it finished? [14:59] klattimer, hey! [15:00] kenvandine: there were two things wrong with vino, first an upstream race condition we couldn't really do anything about, and secondly it didn't show the names of the people connected via telepathy [15:00] the bug is deep and I noticed it gone from my buglist on monday, so I assumed it just got shelved for now [15:00] humm [15:01] klattimer, the get_alias thing looked tough... [15:01] yeah [15:02] what of bug 569273 [15:02] Launchpad bug 569273 in Application Indicators "memory leak in gnome-power-manager (affected: 60, heat: 319)" [Medium,In progress] https://launchpad.net/bugs/569273 [15:02] ah, I was just about to report on that bug when you popped up [15:02] seems gslice always throws crap valgrinds [15:02] there's no longer a memory leak which we can solve, there are leaks, in X [15:02] but I don't think I'll be touching that with a 10ft pole [15:03] klattimer: ah, porting deluge would be a quick and easy win since upstream is willing to take it, likely just go upstream and we'll snag it during N. [15:03] sure [15:03] sense actually said he wanted to take that one back, so I left it for him, but if he's busy with other things I'll go for it [15:03] ok [15:03] apparently it should just be a matter of hooking signals [15:03] he usually comes around nowish [15:04] it'd be spooky if he just appeared then [15:04] 1 2 3, now! [15:04] notta [15:07] hi Cimi, would you mind taking a look at bug 617192 please? :-) [15:07] Launchpad bug 617192 in light-themes (Ubuntu) "[maverick-beta] Disabled menu items unreadable (affected: 20, heat: 123)" [Medium,Confirmed] https://launchpad.net/bugs/617192 [15:10] do we care about bug 526499 [15:10] kenvandine: https://bugs.launchpad.net/indicator-application/+bug/569273 [15:10] Launchpad bug 526499 in indicator-application (Ubuntu) "Application Indicator users launched at start-up skip the applet and fall back instead (affected: 7, heat: 68)" [Medium,Triaged] https://launchpad.net/bugs/526499 [15:10] Launchpad bug 569273 in Application Indicators "memory leak in gnome-power-manager (affected: 60, heat: 319)" [Medium,In progress] [15:10] two branches still need to be merged for that to be fixed [15:11] and that leaves just bug 522152 [15:11] Launchpad bug 522152 in indicator-application (Ubuntu) "indicator-application does not send signals when a menu is shown/hidden (affected: 3, heat: 33)" [Wishlist,Triaged] https://launchpad.net/bugs/522152 [15:13] jcastro: I think the menu open/close signals are implemented in the API [15:13] tedg: ^^ that's correct now isn't it? [15:13] klattimer: if that's the case resolve the bug please, I bet those 2 guys are aching to use appindicators. :D [15:14] klattimer, Those signals aren't coming down right now :( [15:14] tedg: what's the issue? [15:14] do you have other related bug reports [15:14] maybe i'll file this as a dupe? [15:14] looks like we found something for you to do! [15:14] heh [15:18] tedg: what package are the signals implemented in and what's the signal spec string for them, that'd make it easier to get started [15:22] klattimer, Uhm... it may take a diagram :) [15:22] you see ted, this is why we can't have nice things [15:22] tedg: ok if you could do that, that'd be awesome [15:22] klattimer, libindicator -> libapplication.so -> dbusmenu [15:23] tedg: today's your chance to offload bugs to karl [15:23] klattimer, We *just* got this working for indicator-appmenu [15:23] right [15:23] klattimer, So you can't even do it with the libindicator in the distro today :) [15:23] so basically the appmenu works but the other indicators don't send the signal [15:23] ? [15:24] klattimer, libindicator didn't have the function to call. [15:24] :/ [15:24] oh [15:24] When I say *just* I mean like *just* :) [15:25] oh [15:26] right :/ [15:31] klattimer: just a question on bug #558841, can I just take the patch in addition to the previous one, nothing else needed? [15:31] Launchpad bug 558841 in indicator-application (Ubuntu Lucid) "bluetooth "devices" menu item not working in bluetooth indicator (affected: 21, heat: 127)" [Low,Triaged] https://launchpad.net/bugs/558841 [15:31] not in addition [15:31] ok, it replaces [15:31] replace the old patch with the new one [15:31] awesome. Thanks a lot klattimer :) [15:31] np [15:32] didrocks, btw i had kind of tested it... didn't blow up for me [15:32] kenvandine: and did I work? :) [15:32] but i can't disable bluetooth so couldn't show/hide [15:33] in the menu you mean? you can't disable bluetooth? or in the bios? [15:33] i think that needs udev [15:33] menu [15:33] i think the udev in unapproved queue fixes that [15:33] but it's in the queue? [15:34] yeah [15:34] great [15:34] will sponsor gnome-bluetooth then [15:34] thx [15:48] tedg, can you explain more about why you need to poll? [15:48] MacSlow, cnd was asking about the polling in NotifyOSD [15:48] cnd, To do the fading effect as the mouse moves within the bubble. [15:48] I was thinking we should be able to just have a transparent window around the osd area [15:48] and subscribe to MotionNotify events on the window [15:48] and do the fading based on the position of the cursor given in the events [15:49] instead of polling 60 HZ (actually 120 Hz, which should be collapsed to 60 Hz) [15:50] cnd, I'm trying to remember what the issue was there.... I'm pretty sure we tried that. [15:50] MacSlow would probably be the guy to ask as he dealt with the bug reports :) [15:50] cnd, no window... or at least only very small one otherwise the "click-through" is not possible [15:51] MacSlow, click-through? [15:51] oh wait, I think I see what you are saying [15:51] cnd, you know that a user can work through windows (click through them on stuff below it) [15:51] yeah [15:52] MacSlow, why are you listening to mouse clicks in the osd window? [15:52] klattimer, didrocks: i build udev locally and tested the latest gnome-bluetooth patch [15:52] Ah, that's right, we couldn't make it not have input and get the Motion events. [15:52] cnd, the notification-bubbles therefore never get in your flow of work [15:52] works great :) [15:52] they don't seem to do anything? [15:52] cnd, sadly there is no OutputOnly type in X11 [15:52] OutputOnly? [15:52] cnd, so I had to implement it the way it is now [15:53] cnd, yeah... just render stuff and don't care for any input-events [15:53] so the issue is mouse button clicks right? [15:53] you want MotionNotify [15:53] but not ButtonPress or ButtonRelease [15:53] kenvandine: works here even without the udev change :) [15:53] kenvandine: thanks for the info in any case! [15:53] so why not just mask out the Button* events from the window's event mask? [15:53] cool [15:53] cnd, any even the notify-osd window would swallow would be lost [15:53] * kenvandine is glad udev fixes it... need to get that approved [15:54] pitti uploaded it [15:54] cnd, there fore it's input-event mask is a tiny tiny 1x1 rectangle at the top left of each bubble [15:54] MacSlow, actually, this sounds just like what you want an active grab for [15:55] did you look into grabs? [15:55] you would grab and then replay events [15:56] cnd, I wanted to avoid any grabs [15:56] MacSlow, why? [15:57] cnd, let me ask you something... :) what's wrong with the current approach? [15:57] cnd, I still didn't get that [15:57] MacSlow, right now you wake up the cpu 120 times a second [15:58] any time an osd is in effect [15:58] that drains batter [15:58] and spawns a lot of unnecessary process context switches [15:58] it's 60 Hz as far as I know [15:58] MacSlow, there's two timers unfortunately [15:58] they need to be coallesced into one [15:58] but that's still 60 hz [15:58] ideally and idle machine should wake up maybe 10's of times per second [15:59] but this wakes up the proc a lot [15:59] also, cpus have multiple sleep states [15:59] the deeper the sleep, the longer it takes to go into an out of sleep [15:59] cnd, I still don't know server-grabs are that simple to get in [15:59] it may take 5 ms to go into C2, but 15 ms to go into the deeper C4 [15:59] cnd, this is certainly a major change request to notify-osd [16:00] so the kernel won't let you get into C4 with a 60 Hz timer :( [16:00] MacSlow, yeah, I know it's not simple [16:00] but if we can fix it we really need to [16:00] this really will eat people's battery [16:00] especially people who run things like gwibber and have lots of notifications [16:01] it's not something that likely *has* to make it into maverick [16:01] but it needs to be fixed [16:01] cnd, I would need/want a stand-alone test-case/program to verify I get the same click-through- and proximity-fade behaviour with server-grabs [16:01] cnd, proximity-fade is the next issue [16:01] that's fine [16:02] cnd, because they are meant to act upon the mouse moving closer to the bubble (but not withing the bubbles drawing rectangle) they need some other method of getting known to the notify-osd process [16:02] cnd, I'm not sure server-grabs would allow that [16:12] klattimer: sorry I was doing something else, you fine now with some bugs? [16:12] yeah for now [16:12] k [16:23] MacSlow, XInput 2.0 has XIGrabEnter [16:24] it may be possible to do something with that [16:24] cnd, hm... that wasn't in place when notify-osd was started :) [16:24] gtk is supposed to have XI 2.0 soon [16:24] maybe already [16:24] cnd, this is something for the backlog for sure [16:25] yeah [16:25] but it really should be fixed for natty [16:25] cnd, feel free to file that as wishlist item against notify-osd on lp [16:25] cnd, assign me to it so I'll not forget [16:27] ok === mikelifeguard is now known as Mike||gone === rickspencer3_ is now known as rickspencer3 [18:47] klattimer: ping [18:48] sense: do you have a fix for the mono bindings for app indicators hanging around? [18:48] directhex said you were improving his improvements [18:48] klattimer: I just read the merge request approval in my mail box, it should be in trunk already now! [18:48] Including additions to the Python bindings. [18:48] ok, will it make maverick because it breaks this https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/627744 [18:48] Launchpad bug 627744 in tomboy (Ubuntu) "note names are blank in applet menu (affected: 2, heat: 26)" [Medium,Confirmed] [18:48] I believe [18:48] not 100% sure on that [18:49] klattimer: It should not, because it only adds the API additions that weren't previously available in Python and Mono. [18:50] hmm [18:50] bugger :/ [18:50] klattimer: How reliably reproducible is that bug? [18:50] every time [18:50] :/ [18:51] remove indicator applet from the panel and in the status menu it's got no menu items [18:51] Ah! The fallback only? [18:51] yeah [18:53] klattimer: I'm on Unity now, so I'm afraid I cannot test this right away. You were hoping my branch would solve the issue because no one has been able to really pin-point the cause of this bug? [18:53] well someone said that directhex was working on some binding changes [18:53] and he said you were [18:53] so I followed the trail [18:54] ah [18:55] klattimer: This behaviour is not shown by, say, the GNOME Bluetooth AppInd in the fallback mode> [18:55] ? [18:56] chrisccoulson: should be better with the new updates [18:56] to light-themes [18:57] nope [18:58] ah [18:58] klattimer: I'm familiar with the Mono bindings, so maybe I could take a look. [18:58] No error messages anywhere to be found? [18:59] if you would [18:59] not that I could see [18:59] it's just like they're getting misplaced at some point [18:59] sense: https://bugs.edge.launchpad.net/deluge/+bug/584669 [18:59] Launchpad bug 584669 in deluge (Ubuntu) "indicator for deluge (affected: 7, heat: 42)" [Wishlist,In progress] [19:00] jcastro: Good. :) My question was more meant to check whether I should send you the information, but apparently you've got the bug! [19:00] sense: since the upstream guy is keen on it let's just finish it and send it to him and pick it up for Natty [19:00] low hanging fruit [19:01] ok so for tomboy, basically the fix means adding these new API things (signs probably point to NO for those going in maverick) [19:01] jcastro: You mean the app_indicator_set_label() stuff? [19:01] That was merged to trunk. [19:01] the thing that fixes the fallback [19:02] What was that thing? :) [19:02] ok, so from my basic understanding, the tomboy fallback is broken [19:02] right? [19:02] yes [19:02] ok, and to fix that you did ... ? [19:03] I did do nothing to fix that. My branch which was merged a few hours ago added support for the recent API additions to the Mono and Python bindings, i.e. extending their binding definition files. [19:03] "It should not, because it only adds the API additions that weren't previously available in Python and Mono." [19:03] is what we think so far right? [19:03] yes [19:04] Tomboy cannot be using those already, because they weren'ta vailable previously and are still not in stable. [19:04] klattimer: Have you checked your .xsession-errors file, or the indicator-application log? [19:05] I didn't know there was an indicator log [19:05] but xsession seemed OK [19:05] klattimer: I listed some ways of debugging at , I guess you know most, but just to be sure you could take a look. [19:05] k [19:05] cool [19:05] Please extend the page if you have more debugging methods. :) [19:05] klattimer: ok, make this bug a priority then, it's tough to convince people to take a patch when our fallbacks don't work. :) [19:06] yeah true [19:06] I think there's an xfce effort somewhere for app indicator support [19:06] which of course is The Right Solution(tm), heh [19:06] yay [19:08] Whoops. The branch I used to fix the Mono and Python bindings was the branch I used to fix the AppInd part of the Deluge bug. [19:08] The few lines of code I committed in my own branch to solve that are gone now. [19:10] Ah well, it should be still there in the commit history. It's just that it is now harder to find because I removed the association with the bug. [19:17] ok sense now you are just confusing me [19:18] jcastro: The last few lines were referring to the branch that was merged a few hours earlier into the indicator-application trunk. That branch contained a fix for the Mono and Python bindings, but I had previously used (and committed to) the same branch to fix the AppInd side of the Deluge Indicator bug. I had removed the code of the fix in that branch before it was merged, so it is not in any stand-alone branch anymore. [19:30] k [19:30] any other burning indicator-application issues sense? [19:30] I'd like to get klattimer a nice pile o bugs. [19:32] thinking [19:34] hi is this the right place to talk about PPAs, USC, the Linux kernel and Darwin kernel? [19:34] Lollipop56: I"m afraid not. :) [19:34] what would be the right channel then? [19:34] jcastro: bug #601209 is one, but that's more of a feature. Maybe worth looking at bug #493966 and bug #536969 together? Bug #632996 might be something someone else is already working on, or something which Karl is already fully aware of, but I'm mentioning it anyway. Then there is bug #528097, which is an issue in the Mono bindings I promised to take fix, but haven't got around to it, because after spending a lot of time to try to fix that bug it slowl [19:34] y drifted to the back of my consciousness. [19:34] Launchpad bug 601209 in libdbusmenu (Ubuntu) "Indicator breaks gtk table menus (affected: 2, heat: 51)" [Medium,Triaged] https://launchpad.net/bugs/601209 [19:34] Launchpad bug 493966 in Application Indicators "Finish gtk-doc and code samples (affected: 5, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/493966 [19:34] Launchpad bug 536969 in indicator-application (Ubuntu) "The api docs are incomplete or missing (affected: 2, heat: 25)" [Medium,Triaged] https://launchpad.net/bugs/536969 [19:34] Launchpad bug 632996 in indicator-application (Ubuntu) "Vala bindings for libappindicator are incorrect (affected: 1, heat: 384)" [Low,Triaged] https://launchpad.net/bugs/632996 [19:34] Launchpad bug 528097 in Application Indicators "ApplicationIndicator Constructor cannot be overriden in C# (affected: 1, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/528097 [19:35] sense, do you know all those 4 things? [19:35] or someone who does? I wanna talk about i [19:35] it* [19:35] Lollipop56: PPAs are part of Launchpad, so #launchpad might be a start. [19:35] Lollipop56: this channel can be about the Ubuntu Software Centre, but the kernel people are on #ubuntu-kernel, the PPAs are part of Launchpad, which is at #launchpad and Darwin might be suitable for #ubuntu-offtopic, but I'm not sure what you want to say about that to who. :) [19:36] kk, I'll try the kernel channel [19:36] ok [19:36] jcastro: For that last bug you should check if you want me to tell you more about it if there isn't enough info in the bug comments, because it turned out to be reasonably complicated. [19:38] sense: that seems like an adequate pile for now [19:38] klattimer: how's that? [19:38] good [19:46] sense, it's the wrong channel I think [19:46] do you have some basic knowledge about the 4 things? [19:46] Lollipop56: What do you want to know? [19:47] can I pm you about it? I don't wanna start a flame war [19:47] Fine if you want to. :) [19:47] kk [19:47] But this channel is not prone to burst into flames. [19:47] Although we might be off-topic. [19:48] I've never seen this channel rise beyond temperate <., [19:48] *<.< [19:51] * hyperair finds it very interesting that rhythm-e, aka rhythmbox-elementary, looks very much like banshee [19:52] hyperair: chicken-n-egg? ;) [19:52] vish: hmm? [19:52] which was the inspiration? [19:52] banshee, obviously [19:52] the elementary project is a very recent thing [19:52] surely you've heard of nautilus-elementary? [19:53] http://feedproxy.google.com/~r/d0od/~3/Ja-szP46WwU/ [19:53] * vish part of elemenatry team, so i should know ;) [19:53] lol [19:54] well considering banshee 1.0 was.... two years ago? [19:54] i think banshee's new interface came first [19:54] vish: i like the stuff the elementary team is doing. [19:54] just one issue: nautilus-elementary's breadcrumbs are buggy [19:54] try opening a deep path [19:55] i mean a very long path [19:55] yea, n-e has a lot of bugs , dont tell seb128 though ;p [19:55] lol [19:55] why not? [19:55] a lot of bugs filed in nautilus nowadays turn out to be due to users actually using n-e ;p [19:55] argh [19:55] lol! [19:55] hyperair: Or did iTunes blow them both out of the water by way of precedent? [19:56] gambs: nah, itunes looks rather different. [19:56] Everything draws inspiration from other sources, but sometimes it is just more obvious. [19:56] gambs: rhythm-e is much more similar to banshee than either is to itunes. [19:56] I would say that Rhythmbox is more like iTunes than Banshee. [19:56] Still pioneered the basic layout that both derive from. [19:57] Controls in the upper left, track data and seek bar center-ish, search on right. [19:57] sense: what about rhythm-e? [19:57] Side bar for organization. [19:57] the sidebar could have come from anywhere [19:57] nautilus does it [19:58] windows explorer does it [19:58] it's too common a concept to point at itunes. [19:59] anyway nothing beats banshee's searching capabilities [19:59] I'm just saying, those things in conjunction, that layout, was made popular in iTunes. There's no reason to discount it other than unnecessary hate. [19:59] hyperair: haven't looked at that [20:00] gambs: who mentioned anything about hate? =) [20:00] i personally think itunes UI is messy and cluttered. [20:00] they crammed too many things there [20:00] banshee's is just nice [20:02] I disagree on Banshee not having too many things crammed in there, but that's me. XD (The drop down from the next track button comes to mind immediately as very 'crammed in') [20:19] Cimi, have you seen bug 622284 ? [20:19] Launchpad bug 622284 in light-themes (Ubuntu Maverick) "Font blur on some buttons in Ambiance/Radiance theme (affected: 5, heat: 24)" [Medium,Confirmed] https://launchpad.net/bugs/622284 [20:32] kenvandine: just update murrine [20:33] ah, that should be fixed with the murrine release? [20:37] kenvandine: yep [20:37] great, thx [20:37] I fixed that 13 days ago [20:37] Cimi, that is uploaded, just waiting to get pushed through the queue to get built [20:39] Cimi, thx [20:40] no worries :) [23:00] Where would be a good place to bring up a discussion about applications stealing focus or not stealing focus? When they pop-up/where?