[01:58] Nafai, jono: Submenus branch is posted. Will hopefully go through review and be available in trunk tomorrow. [02:15] bratsche, awesome, thanks! [02:47] bratsche: Thanks a ton! I'll let you know how it works out :) [04:02] status sent out. kind of exhausted, headed to bed excited for hard work tomorrow. === kenvandine_ is now known as kenvandine === MacSlow is now known as MacSlow|pizza === MacSlow|pizza is now known as MacSlow [14:08] Good morning [14:51] Nafai, ok our job this morning is to bug Ted/Cody/whoever until you're unblocked [14:52] Thanks [14:54] Looks like I'm just waiting for Cody's changes to come to the repo, he changed the status of the bug to Fix Committed, some hopefully in not too long I can work on Gnome Bluetooth [14:56] To make the ibus app indicator work like in the status icon the application indicator menu would need to not get focus, but that would break keyboard navigation inside the menu [14:57] I have a workaround for ibus which makes it work as good as possible when the input field looses focus to the menu [14:57] it is bug 497878 [14:57] Launchpad bug 497878 in ibus (Ubuntu) "Support Application Indicators (affects: 1)" [Undecided,In progress] https://launchpad.net/bugs/497878 [14:58] whom should I assign it for review? [15:00] It would also be good to have support to set the app indicator icon by filename [15:01] For the display setting application indicator we would need support for signals when the menu is opened/closed (to display labels on the monitors) [15:02] And some custom drawn menu items (to match the labels on the screens) [15:16] jcastro: I took a minute to look at policykit-gnome, and I'm not seeing any use of GtkStatusIcon [15:20] Nafai, don't waste work on that, polkit-gnome is deprecated [15:20] we use polkit-1 now [15:21] seb128, ok [15:22] Ok, perhaps the bug for the work was mis-filed [15:22] thanks [15:22] seems so [15:22] and policykit-1-gnome does use GtkStatusIcon [15:22] they filed bugs based on some grepping [15:22] oh [15:23] reassign the bug then [15:23] (don't close the task and open a new one) [15:23] ok [15:23] right, polkit-1 displays an icon with keys you can click on to revoke authentification [15:23] should be trivial to port I guess [15:24] it's one menu with one entry [15:26] jcastro: I reassigned the bug to the package policykit-1-gnome [15:26] https://bugs.edge.launchpad.net/ubuntu/+source/policykit-1-gnome/+bug/497881 [15:26] Launchpad bug 497881 in policykit-1-gnome (Ubuntu) (and 1 other project) "Support Application Indicators (affects: 1)" [Undecided,New] [15:26] ok [15:27] it seems that the source on git.gnome.org though is for the old one though [15:29] seb128, I need to adjust the upstream bug as well right? [15:29] jcastro, I don't know if they created new components for the new version [15:29] jcastro, ask pitti maybe [15:29] I don't see one [15:29] ok [15:29] he probably knows [15:30] ok no change in the upstream name in bgo [15:31] Nafai, did cody's fix land so bluetooth can be finished today? [15:32] jcastro: not yet, though the bug says fix committed, so I hope it lands sometime today [15:33] ok and you just need a response to the brasero mail to finish that off? [15:33] yeah, that response will help both brasero and vino [15:33] where is cody change? [15:33] Nafai, which bug was the submenu one? I can see if it built [15:34] https://bugs.launchpad.net/indicator-application/+bug/519625 [15:34] Launchpad bug 519625 in indicator-application "Submenus don't appear to be supported (affects: 1)" [Undecided,Fix committed] [15:34] I can upload that to lucid if you guys need it [15:35] yes please! [15:39] Nafai, ok so I'll ambush ted and bratsche when they arrive [15:40] Thanks, I appreciate it :) [15:40] also, https://bugzilla.gnome.org/show_bug.cgi?id=606972 [15:40] Gnome bug 606972 in User Interface "Support for application-indicators/StatusNotifierIcon" [Enhancement,Unconfirmed] [15:40] that was cody's patch but I bet he will have no time to look at it, so I guess jono will assign it to one of you to finish off [15:41] Looks like it is updating the rb support for upstream? [15:42] yeah, it was our first example [15:42] we've been carrying it in lucid for a while, just needs the extra love to get upstream [15:43] oh please somebody do update that one to current git [15:43] I wanted to do a rhythmbox git snapshot soon [15:43] I can do that after I finish this stuff :) [15:43] thanks [15:43] I will get the submenu change uploaded meanwhile [15:44] so you can go back to bluetooth after rhythmbox ;-) [15:44] seb128, any love to get that built quickly would be <3 [15:44] bribe someone for a higher score! [15:47] So the Application Panel Indicators (https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators) seems to work somewhat different than the proposed desktop standard (http://www.notmart.org/misc/statusnotifieritem/index.html). Can anybody shed some light on this? To me it seems like there are two standards being implemented right now. jono 's blogpost gives the impression of only one standard. (http://www.jonobacon.org/2010/02/10/kde-application-in [15:48] seb128: Just to make sure what you mean, "Update the current one to git", make the current patch work with rb git? [15:49] GogglesGuy, tedg is the person to ask [15:50] Nafai, I plan to update rhythmbox in lucid soon [15:50] Nafai, so if you have a patch updated for what is in git it will make my job easier ;-) [15:50] ok, awesome [15:50] can do [15:50] Nafai, ie it will not block my update [15:50] Nafai, thanks [15:50] upstream wants it updated to git anyway so 2 birds ... [15:52] Should I just grab the patch from the debian/patches directory and work from there? [15:53] jcastro: thanks, I'll wait for tedg then :P [15:54] heh, the line lengthens [16:16] hi bratsche! [16:17] Hey [16:17] bratsche, could you answer Nafai's mail so he can finish off brasero and vino? [16:17] Nafai, yes [16:17] Let me check [16:17] hey bratsche [16:17] bratsche, sorry no ted today, so we're going to pile up on you instead. :D [16:18] heh [16:18] Hey seb128 [16:18] seb128: thanks [16:23] Nafai: Let me pull down the code to brasero and see what you mean. I'm not sure I really understand what you're asking. [16:23] sure, I sometimes I'm a little unclear :) [16:26] Nafai: Okay, so brasero has BraseroTrayIcon that derives from GtkStatusIcon and you want to make something that's compatible with both? [16:27] the ultimate goal is to not copy and paste code to duplicate the functionality of BraseroTrayIcon in BraseroAppIndicator [16:27] What seems natural is to make a new parent class, not have BraseroTrayIcon inherit from GtkStatusIcon, and go from there [16:27] But that feels pretty invasive, and am not sure how upstream would receive it [16:27] Nafai, using i386? [16:27] Vino is designed similarly [16:28] seb128: x86_64 [16:28] yay for manually resolving patches [16:29] Nafai: One possibility is to have configure.ac check for the existence of app indicators and set HAVE_APP_INDICATORS or whatever, then if it's set provide a different implementation of BraseroTrayIcon at compile time and try to keep the .h file pretty much the same. [16:30] Nafai, the updated indicator-application built now [16:30] Nafai, you can get the debs on launchpad or wait next publisher run [16:30] thanks [16:31] I'm still working on rhythmbox, manually updating patches is fun :) [16:31] Another possibility, but which is probably more work than we want to invest into a single application now, is to define a GInterface that abstracts between an app indicator and a GtkStatusIcon and then have a factory method to create the appropriate implementation. [16:32] Yeah [16:32] Hrm [16:35] bratsche, fyi: https://bugzilla.gnome.org/show_bug.cgi?id=606972 [16:35] Gnome bug 606972 in User Interface "Support for application-indicators/StatusNotifierIcon" [Enhancement,Unconfirmed] [16:35] bratsche, nafai is looking at it [16:35] * bratsche clicks [16:36] Cool. [16:36] so, have ifdef's in the .h file depending on if HAVE_APP_INDICATOR is defined. If it is, change the parent class to GObject instead of GtkStatusIcon, then in the implementation, have appropriate ifdefs to do the differences [16:36] so using the preprocessor to define what the class actually does [16:37] Nafai: Well, how about this: [16:37] Copy BraseroTrayIcon into a new file, brasero-indicator.[ch] and reimplement it using app indicators. Change what it derives from so it's not GtkStatusIcon. Then do all the if HAVE_APP_INDICATOR stuff in the build system. [16:38] So then the sources include brasero-tray-icon.c if it's not defined, or brasero-indicator.c if it is. [16:38] well, I've already done that, but that leaves portions that are identical between brasero-indicator and brasero-tray [16:38] which is what I'm trying to avoid [16:38] (again, sorry if I'm not explaining this well) [16:38] Oh I see. [16:39] for example, when a given menu item is clicked, do this action [16:40] vino is worse, I think I would have to copy and paste a lot more code, and the differences would only be a line or two in each method [16:41] Can you have a wrapper object that holds either a statusicon or indicator object, and which contains the common code like signal callbacks? [16:41] that might make sense [16:42] If all else fails then you may just have to #ifdef HAVE_APP_INDICATORS / #else / #endif in your code. [16:43] Ideally we want the code to be good to send upstream, but at the end of the day the primary goal is to just get through the list of applications so we can ship them in Lucid. [16:43] right [16:43] I've got far enough with brasero and am familiar enough that I could easily prototype this change [16:43] So I'd probably say if you're stuck on something like this, just do something slightly hacky if you need to in order to get through the list and make notes about which apps you can come back to and improve the quality of. [16:43] jcastro: opinion? [16:44] I think that makes sense. [16:44] I'm concious of getting it in the distro asap before the deadline [16:45] after that if they slice it apart and we have to iterate a bunch of times then that's what we'll have to do [16:45] so for the first deadline, we can accept there is some copy and pasted code, but with the plan to go back and fix later in the cycle, so that we can feel like there is something we can share upstream [16:46] yes, except I would be more comfortable submitting the code in the upstream bug anyway so they could at least see what we're doing [16:46] ok, with the caveat, saying "Hey, I know there is this problem...what would make you more likely to accept this?" [16:46] Nafai, and perhaps lay out a little rationale and what conclusion you came up with (ie. a little summary of the conversation you just had) [16:46] good idea [16:46] right [16:47] that would at least kick off the conversation [16:47] ok, good [16:47] bratsche: thanks for the ideas, sorry if I was unclear [16:48] gnome is mostly frozen for this cycle anyway, so it's not like we have a deadline looming to get it accepted upstream. [16:48] I'm going to go take a little break, I'll get back and work on updating the rb patch, then I'm really not blocked on brasero, vino, and gnome-bluetooth [16:48] so I've got plenty to keep me busy today :) [16:48] steady progress on each bug will be the way to go I think [16:48] def. [16:48] bbiab [16:48] Thanks for your work Nafai [16:50] i just updated my lucid and got the volume control indicator. few probs [16:51] 1. i cant change the volume using keyboard i can just use the up down keys on kb to scroll up and down the menu items but not change volume. [16:51] 2. now i can no longer change the volume with my mouse scroll wheel by just the notification area icon. more clicks reqd [16:52] 3. once the indicator menu is opened. mouse scroll down increases volume and scroll up dec it. imho this should be reversed [16:52] should i file bugs for them? [16:54] Nafai, when you get back concentrate on finishing the apps, then go back to rb. [16:55] tgpraveen12, someone's already filed a bug on 2. [16:56] bug# if u have handy? [16:59] bah, can't find it now [16:59] https://bugs.edge.launchpad.net/ubuntu/+source/indicator-sound/+bug/521046 [16:59] Launchpad bug 521046 in indicator-sound (Ubuntu) "can't change audio using mouse wheel (affects: 2)" [Undecided,Confirmed] [17:00] thx, [17:01] tgpraveen12, yes open bugs [17:01] ok [17:58] jcastro: Okay [17:58] darn tv, stupid distractions :) [18:24] Okay, that's a little closer with bratsche's changes [18:25] http://www.travishartwell.net/bluetooth.png [18:25] Nice. [18:25] I'm sure it's something I'm not doing now [18:25] I'll let you know if it isn't [18:26] Nafai: Keep rocking dude! [18:26] :) wee, thanks! [18:42] Nafai, looking good! [18:42] Hopefully I can track down the issue real quick like ;) [18:42] Nafai, when do you end-of-day? if you don't mind I'd like to do a quick call and go over each app so I can have an updated status [18:42] generally around 5 or so mountain [18:43] Nafai, so let's do a call around 2.5 hours or so? [18:44] sure [18:44] works for me [19:15] just verifying, I can't get the menu open event? gnome-bluetooth uses that to cancel any notifications that are on screen [19:40] HI tedg [19:40] quick question for you :) [19:40] Nafai: Heh, okay. [19:40] just verifying, I can't get the menu open event? gnome-bluetooth uses that to cancel any notifications that are on screen [19:41] they have a popup_activate signal [19:47] Nafai: It has been the plan to add one... but it's getting really close to feature freeze, so I don't know if it'll make it. [19:47] Nafai: It shouldn't be an issue though. [19:47] okay, I can leave that part as a "TODO" [19:47] Nafai: As the reason that gnome-bluetooth does that is because of notification-daemon, and notify-osd handles this much better. [19:47] oh, good to know then [19:48] tedg: So the Application Panel Indicators (https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators) seems to work somewhat different than the proposed desktop standard (http://www.notmart.org/misc/statusnotifieritem/index.html). Can anybody shed some light on this? To me it seems like there are two standards being implemented right now. jono 's blogpost gives the impression of only one standard. (http://www.jonobacon.org/2010/02/10/kde-applicat [19:49] Hrm, I'm seeing this in my indicator-applet.log, I wonder if this is part of the reason my menu is funky and showing things it shouldn't: [19:50] Indicator Item property 'visible' unknown [19:50] Is that for one of the icons or for a menu item? [19:51] GogglesGuy: The KSNI spec defines the "how" of how applications can communicate with visualizations over dbus. But, it provides very little of what that actually means. AppIndicators take a few of the values in KSNI and say exactly how we are going to use them. So an Application using AppIndicators will work in KDE as it still follows the how provided by KSNI and applications that work with KSNI will work in AppIndicators, just not a [19:51] Nafai: Probably for a menu item. It should be 'enabled'. [19:52] Nafai: Oh, wait, sorry. [19:52] Nafai: That's from libindicate, it's probably not related. It's from the messaging menu. [19:52] oh, okay [19:58] tedg: I understand that the implementations may differ on how they interpret certain aspects of the spec, but for example the "Menu" property in the current implementation is required for a status icon to be visible but the spec doesn't have such property. Hence anyone following the spec won't be invisible in that case. [19:59] ahah [19:59] I figured out what is going on [20:00] tedg: so you pass a menu to the app-indicator's API, it parses it and then passes the structure over D-bus to the service? And then the applet recreates it? [20:00] GogglesGuy: Yes, we're working with the KDE folks and I believe the plan is that they'll add it (if they haven't already). We've written the code for KDE libs so that it adds that as in KDE you provide a menu, it was just shown as a popup with the secondary click event instead of through dbusmenu. [20:01] Nafai: Correct. [20:01] ok [20:01] Nafai: That way on KDE the menu gets recreated in QT and looks native to the panel there. [20:02] so gnome-bluetooth updates the menu after it is set on the status icon, including hiding items, etc. so I need to set the menu again whenever the menu changes? [20:03] tedg: I'm hunting down the bug that I've asked about in this channel a few times already and I've got a question about the way Indicator-Application handles the labels of the GtkImageMenuItems. Somehow AppInd seems to use the stock label when a stock icon has been set, even when a custom label has been set. [20:04] Nafai: You shouldn't have to. I'm unsure how updating works -- that'd be a question for bratsche [20:04] okay [20:04] qense: Okay. Sounds like a bug to me. [20:06] tedg: It's reporter already, but I wanted to see if I could find its cause. I should have asked what I wanted to ask with my previous question -- I was far from clear -- where does AppInd get the MenuItem label from when setting the MenuItem label? The DBus property 'label', or the GtkImageMenuItem's 'label' property? [20:06] bratsche: Around? [20:07] tedg: so do I understand correctly you want to support both the "Activate" "ContextMenu" etc methods and the dbusmenu method? [20:07] Nafai, tedg: Yeah, right now I think it's only parsing through the menu when you set it. Let me look to see what's involved in having it update it automagically. [20:07] ok :) [20:08] qense: If you grab lp:indicator-application then go to src/libappindicator/app-indicator.c you can see. Just search for "STOCK" :) That'll probably answer your next two questions too ;) [20:09] tedg: OK, thank you for your time! [20:09] GogglesGuy: We're not going to use those methods with the appindicator service running on Ubuntu, but applications using libappindicator will fallback to using them if the dbusmenu support isn't there. [20:09] I see [20:10] ah, found the bug! [20:10] Nafai: I'll cook up a patch for it right now. [20:10] bratsche, Awesome! [20:12] tedg: Iyou do know that the first bugs/feature requests that people will report is mouse wheel scrolling, right click context menu and the activate click support. [20:13] okay, this is a good time to take my lunch [20:13] Much of the GtkStatusIcon didn't support for a very long time [20:13] GogglesGuy: Oh, they already have :) [20:14] tedg: Mind you I do like the way dbusmenu would work, but perhaps you should be able to specify that either for a right click or left click... :) [20:14] Only the mouse wheel scrolling is worth saving, all the others conflict with the design document. [20:15] qense: I think the design document doesn't match reality though... [20:15] GogglesGuy: The thing that we want is them to behave consistently and like normal menus. Which don't work differently depending on the mouse button you use. [20:17] That's one of the things I like about app-indicators [20:17] I never know if I need to left-click or right-click to get functionality (or specific functionality) out of things in the notification area [20:17] Where is the documentation for libdbusmenu? I'd like to take a look at the reference manual of DbusmenuMenuitem. [20:17] Nafai: indeed, I like consistency [20:21] qense: I don't have it generating anywhere right now. :( The functions are documented though. [20:21] qense: lp:dbusmenu [20:22] It would be nice to get that stuff into devhelp. [20:22] tedg: That's fine, I just found the code myself. Thanks for providing it as well, though. ;) [20:22] bratsche: indeed, there is way too little documentation from Ayatana in Devhelp atm [20:22] bratsche: Yeah, it's just a PITA to set up gtk-doc so I haven't done it yet. [20:22] I think we have libindicate in there, but nobody has gotten around to libdbusmenu. [20:22] An libappindicator is there as well. [20:23] I need to figure out how to get gtk-doc to make nice web docs as well. [20:23] tedg: i *think* i found how gnome-main-menu orients the menu to the panel , but now sure how to apply it to the application indicators > Bug 498182 [20:23] Launchpad bug 498182 in indicator-application (Ubuntu) (and 1 other project) "Indicator-application does not support vertical panels (affects: 1)" [Undecided,New] https://launchpad.net/bugs/498182 [20:23] comment 1 [20:23] tedg: Do we have bugs open for the modules missing gtk-doc support yet? [20:23] I'm sure it's not impossible, as everyone else does it, but I've never really tried. [20:24] bratsche: We had a couple, I'm not sure about for all of them though. [20:24] tedg: Isn't there a default, already good-looking, template from gtk-doc? [20:24] a better looking than what appindicator is using now? [20:25] vish: Well that's because the panel is using a box for packing, we're using a MenuBar, so it's probably be a bit different. [20:25] hmm.. :( [20:25] What's the problem? [20:25] qense: There's templates, but I think the bigger issues is getting it linked in with stuff like gtk.org for the GTK+ docs. It's possible to do, I'm just not sure how. [20:26] bratsche: application menu does not switch[re-orient] when the panel is vertical panel [20:26] the icons get hidden out of the screen [20:26] well, you're probably already busy enough with actual development, so It's understandable. Isn't there a specific documentation team that knows these kind of things? [20:27] bratsche: i thought i could use the gnome-main-menu code for that , but guess I'm lost :( [20:27] qense: Sounds great, you should start one ;) I imagine it's just figuring out what library.gnome.org does and copying it. [20:27] tedg: I wish I had the time to do so. :) [20:28] vish: Does it expose GtkOrientation somewhere? [20:31] bratsche: not really sure [20:31] * vish checks [20:32] bratsche: gnome-main-menu does not [20:35] http://library.gnome.org/devel/panel-applet/stable/PanelApplet.html#PanelAppletOrient [20:35] http://library.gnome.org/devel/panel-applet/stable/PanelApplet.html#panel-applet-get-orient [20:37] vish: That might be a good place to start from if this is something you're interested in hacking on. [20:38] hmm.. bratsche thanks.. will have a look [20:39] vish: I don't have time to work on this right now, but if you're interested in it then I can try to help you out some. [20:40] bratsche: but that^ part i think wont work , since tedg mentions app indicator uses the menubar , while gnome-mani-menu uses the box [20:40] vish: Yeah, but app indicators still live inside a panel applet ultimately. So that applet would need to know its orientation and then communicate that to the indicator. [20:41] ah, ok [20:41] bratsche: i'll try to check how to make it work and get back to you :) [20:42] vish: Oh, and lastly you'd need to listen to this signal: http://library.gnome.org/devel/panel-applet/stable/PanelApplet.html#PanelApplet-change-orient [20:44] cool , thanks.. [20:57] bratsche: fiiiix! [20:57] ahem [20:58] bratsche: I've written a fix for the bug that was bugging me a few days ago and that I assigned to you [21:06] Fantastic! [21:06] What's the url? [21:10] bratsche: I just submitted a merge request assigned to you, for branch lp:~qense/indicator-application/fix-520048 , of course a fix for bug 520048 [21:10] Launchpad bug 520048 in indicator-application "Custom labels in GtkActionEntries aren't resepected by Application Indicators C-bindings (affects: 1)" [Undecided,In progress] https://launchpad.net/bugs/520048 [21:11] I've tested it and it seems to work very well. [21:11] Cool, I'll take a look at it. [21:11] bratsche: thanks [21:12] Nafai: I'm posing lp:~bratsche/indicator-application/menu-changes - do you have time to see if this fixes the issues you were having in gnome-bluetooth? [21:12] s/posing/posting [21:12] Sure, what's the best way to test it locally? [21:13] tedg? ^ [21:13] kenvandine, is the sound indicator shipped in Lucid? [21:13] I just dist-upgraded and see no volume control [21:13] jono: yes [21:13] I have it running here. [21:13] did you reboot/relog? [21:13] qense, yep [21:13] rebooted [21:14] jono: It might not be installed by default yet, try installing indicator-sound. [21:14] Nafai: Best way... [21:14] tedg, ahhh thats it [21:14] Do you have to relogin after installing indicator-sound? [21:15] Nafai: Probably the best way is to merge it into a local packaging branch. [21:15] bratsche: killall indicator-applet will work. [21:15] tedg: https://code.launchpad.net/~qense/indicator-application/fix-520048/+merge/19201 [21:15] tedg: You want to review this as well? It looks fine to me. [21:15] tedg: What's the packaging branch named? [21:16] wow [21:16] Nafai: lp:~ubuntu-desktop/indicator-application/ubuntu [21:16] I am getting spammed by indicator applet quit unexpectedly dialog boxes [21:16] Thanks [21:16] bratsche: I have already signed the Contributor Agreement, if that's required [21:17] * jono uninstalls sound-indicator :) [21:17] indicator-sound, rather [21:17] jono, it should be there by default [21:18] he's quit already [21:18] saw that :/ [21:18] tedg, how do I start indicator applet? [21:18] what is it called? [21:18] jono: Right-click the panel and click the "add" thing. [21:18] It's called Indicator Applet. [21:19] ahhh yes [21:19] thanks bratsche :) [21:19] but it doesn't contain the volume control thing [21:19] it should [21:19] and the old one shouldn't be there anymore [21:19] I really want to convince someone to reverse the mousewheel events for indicator-sound though. [21:19] seb128 killed it earlier [21:19] Was it moved from indicator application to the applet? [21:19] Because I'm used to mousewheel-up increasing the sound. [21:20] qense, they all hang off the indicator-applet [21:20] ah, I never knew that [21:20] stuff using indicator-application also are attached to it :) [21:20] yup :) [21:20] tedg, bratsche: thanks for approving [21:20] brb [21:30] Is this already linked to from some places? It contains a neat list of applications that still need Indicator Applications support. [21:32] qense: I think so, jcastro would know ^ [21:33] qense, yep that's it. [21:33] tedg, jcastro: good [21:34] qense, there are tons in universe which probably need bugs, however talking to the upstream directly can be quicker. [21:35] uh, so I'm new to bzr, what do I have to do to merge cody's changes with the packaging branch? [21:35] I have them both checked out [21:35] I thought I did it, but it doesn't look like it [21:36] jcastro: if only we could get that list done I'd be very happy [21:36] Nafai: bzr merge ../path/to/branch-you-want-to-merge [21:36] qense, Nafai's got like 3 pending ones to land here shortly [21:36] splendid! [21:36] Yeah, I'm really close :) [21:37] qense, Okay, I did that, but it is saying I have pending merges when I do bzr status [21:37] you did mark those bugs as In Progress, did you? [21:37] bzr commit should fix that iirc [21:37] thanks [21:37] I'm used to git :) [21:38] Nafai: you can associate a commit with an LP bug with the command 'bzr commit --fixes lp:bug_number', btw [21:38] Yes, mine are "in progress" [21:38] ok, I just wanted to be sure ;) [21:38] qense, seahorse could use a look if you want to get into Vala [21:38] jcastro: are the Vala bindings already included? [21:38] I was looking forward to that :) [21:39] I don't want to steal Nafai's fun. ;) [21:39] qense, I believe njpatel has some mostly-finished-stuff that with some prodding would make him finish them [21:40] jcastro: is that bug #510610, or is it somewhere else? [21:40] Launchpad bug 510610 in indicator-application "Add Vala bindings (affects: 3)" [Wishlist,In progress] https://launchpad.net/bugs/510610 [21:40] yep, that's it [21:41] ok [21:42] qense, if you want an easy one look at gnome-gmail-notifier [21:42] does anyone actually use that still? [21:42] I do! [21:42] but it uses Bonobo! [21:42] heh [21:42] I want something that works [21:42] and the whole libgnome stack [21:42] qense, ok, how about banshee or epiphany or ekiga? [21:42] But gnome-gmail-notifier isn't installable [21:43] It needs to be updated to use a new version of libsoup [21:44] bratsche: I'll work on a small test case for the insensitivy issue next week [21:44] I'll probably take a look at Banshee, since I'm using it myself as well and would want it to use AppInd. It does use quite a 'sophisticated' tray icon system. Lots of classes, etc. [21:44] Nafai: jcastro can make everything install when he wants it to [21:44] qense, upstream (abock) has shown interest, but doesn't have time to do the work [21:44] qense, I think he wouldn't mind losing the crack [21:44] Nafai: I posted the branch that watches for visibility changes, so that should fix another issue you're having for gnome-bluetooth. [21:45] probably [21:45] bratsche: oh, cool. [21:45] I'm having problems getting this to build in pbuilder [21:45] gnome-gmail-notifier: Depends: libsoup2.2-8 (>= 2.2.98) but it is not installable [21:45] qense, Yes, that's the problem :) [21:46] I'm reporting the bug [21:48] qense, can you confirm that g-c-c is using the app indicator when you get a chance? https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/497857 [21:48] Launchpad bug 497857 in gnome-control-center (Ubuntu) (and 1 other project) "Support application indicators (affects: 1)" [Wishlist,Fix released] [21:49] I just fired it up but it went in the old tray [21:49] jcastro: will check [21:49] jcastro: Do you have the very latest package? [21:50] Nafai, I have a bunch of updates of libappindicator stuff [21:50] * jcastro upgrades [21:50] hrm [21:50] It is working for me :) [21:50]