[00:34] Getting closer to with vino.... [00:35] bbiab, getting dinner [02:07] Yay for added complexity [02:11] Gotta change some things around -- it was easier with GtkStatusIcon, you could hook up to the activate event and build the menu on the fly [11:36] MacSlow: Could you take a look at this merge request: ? You accepted it a while ago, but probably forgot to do the actual merging while I was being asked to sign the Canonical Contributors Agreement. [11:43] qense, did you sign that? [11:43] yes [11:43] MacSlow: I already contributed a few lines to some other projects that require it as well [11:44] qense, I currently can't verify with dbarth as he's not online... but will merge it in as soon as I can get hold of him [11:44] MacSlow: thanks! [11:44] np [11:44] maybe there should come a team for people who have signed so it's easier to verify [12:36] bratsche: Sorry to bother you, but could you take a quick look at bug #526620? It's blocking my work on Banshee. I wouldn't mind trying to solve the bug myself, I just need someone with more experience to tell me what could cause this and if it matters that all signal names and variables use a underscore, whereas the variables in the header, .e.g. APP_INDICATOR_SIGNAL_CONNECTION_CHANGED, use a hyphen, e.g. "connection-changed". [12:36] Launchpad bug 526620 in indicator-application "ApplicationIndicator signal names not set in C#/Mono bindings (affects: 1)" [Undecided,New] https://launchpad.net/bugs/526620 === MacSlow is now known as MacSlow|lunch [12:45] (afk) [13:14] hello, i'm trying latest lucid iso and seems like python bindings for libappindicator are still "broken" [13:14] i correctly managed to update the menu in the indicator calling set_menu everytime i add/remove items [13:15] but still, i cannot set the icon-theme-path property [13:15] it's complaining i must set it in the constructor, even if it's not the case since there's no such argument [13:26] (back) [13:27] C10uD: Have you tried passing the path as the fourth argument to the constructor? [13:27] maximum 3 arguments allowed [13:28] C10uD: then I'd search for a bug report describing the issue and if you cannot find one, report it. [13:32] qense, there's a similar bug, triaged by you.. [13:32] C10uD: ok, then please add your information to the report. [13:32] basically that was the exact thing i needed, but here i was told to use icon-theme-path instead [13:33] you already answered as "won't do it" [13:33] C10uD: Ah, that bug report. I would file a separate bug for the Python bindings. [13:40] ok, here's the bug [13:40] https://bugs.launchpad.net/indicator-application/+bug/527061 [13:41] Launchpad bug 527061 in indicator-application "python bindings for libappindicator don't allow to change icon-theme-path (affects: 1)" [Undecided,New] [13:42] C10uD: thank you! [13:44] thank you if you fix it, i'm waiting for getting that fixed so i can release emesene with appindicator support :p === MacSlow|lunch is now known as MacSlow [15:05] qense: when ted get's on let's bug him on lp #527061 [15:05] Launchpad bug 527061 in indicator-application "python bindings for libappindicator don't allow to change icon-theme-path (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/527061 [15:05] qense: you around? [15:05] qense: also, seb is starting to see bugs come in on apps that have been patched, I have been tagging them and then just assign them to the person who ported the app [15:05] nigelb: yes I am [15:05] jcastro: What tag are you using? [15:05] qense: need a little bit of hand with python [15:06] qense: indicator-application still [15:06] nigelb: Ask whatever you want [15:06] jcastro: ok [15:06] btw, tedg is already here [15:06] tedg: could you take a look at bug #527061? [15:06] Launchpad bug 527061 in indicator-application "python bindings for libappindicator don't allow to change icon-theme-path (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/527061 [15:06] according to my calculations he should be on a call right now [15:06] ah [15:06] I didn't know that [15:07] qense: take a look at the masking code. I'm not sure how to do it. http://pastebin.com/XTrQLPGD [15:07] qense: Yeah, I can look after my call. But for Python stuff kenvandine is probably going to be mroe helpful. [15:08] tedg: ok, thanks anyway! [15:08] hey tedg jcastro [15:08] jcastro, tedg: the checkbox not updating in appindicators menus issue is supposed to be fixed in lucid? [15:09] seb128: No, I haven't investigated what happened. [15:09] ok [15:11] I'm trying to figure bug #527061 out atm, in case some of you had some spare time and wanted to do this bug/ [15:11] Launchpad bug 527061 in indicator-application "python bindings for libappindicator don't allow to change icon-theme-path (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/527061 [15:11] ahem, wrong bug [15:11] bug #527082 [15:11] Launchpad bug 527082 in indicator-application "CONNECTION_CHANGED signal (connection-changed) is never emitted (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527082 [15:17] afk, nigelb: I'll get back to you when I'm back [15:56] jcastro, bug #526864 [15:56] Launchpad bug 526864 in rhythmbox (Ubuntu) "next/previous buttons are greyed out in indicator application menu (affects: 1)" [Undecided,New] https://launchpad.net/bugs/526864 [15:56] jcastro, can you get that one assigned? [15:56] done [15:56] thanks [16:04] Good morning [16:04] hey Nafai [16:04] Hey seb128, how are you today? [16:05] Nafai, good! you? [16:05] Pretty good [16:36] I can't solve the signal problem, moving on to one of the many other things on my ToDo list. [18:16] Nafai: how we feeling today? [18:16] Nafai: jpetersen busted out polkit-1-gnome so we're on the homestretch now! [18:17] Sweet [18:17] doing well, I'm just heading to my dr's appointment, be back in a couple [18:17] cool [18:17] good luck! === mpt_ is now known as mpt [20:08] jcastro: Back, I've actually started feeling pretty bad, my kidney function is the worst it's been since my transplant, so I need to go rest for a while so I can have the energy to focus on pushing vino out [20:10] Nafai: no worries, hope you feel better [20:10] thanks [20:32] have you guys collaborated with gnome folks on their usability hackfest? [20:32] kklimonda: it's hosted at the Canonical offices [20:33] well, that was the answer I was hoping to get :) [21:35] Damn. How did I miss qense *again*? [21:36] he's like a ninja ;) [22:15] Ok, I'm back, feeling much better after that rest [22:24] qense: Hah! Caught you :). [22:24] RAOF? [22:24] qense: Thanks for the gnome-do application-indicator work; I've spotted your problem. [22:25] RAOF: really! Great! [22:25] tell me! [22:25] Basically, you can't use other services is a service constructor. [22:26] I've pushed up a branch of Do that works, but doesn't have any compile-time switch. [22:26] lp:~raof/do/throwaway-app-indicator [22:26] throwaway? [22:27] It's a throwaway branch; it will only work with app-indicators. [22:27] ah [22:27] It just shows working app indicator code. To do that quickly, I got rid of the GtkStatusIcon code. [22:28] The main change is the use of IconTheme.Default.HasIcon ? [22:28] Main change is moving the construction of the menu into Initialize, rather than the constructor. [22:28] ah [22:29] important [22:29] The constructor will be called before the service stack is fully available. [22:29] ok, that explains a lot :) [22:29] Which is why you were seeing a stack overflow :) [22:30] RAOF: Thank you very much for helping me with this! [22:30] No problem. [22:30] How's Banshee going? [22:31] Banshee's going fine, but I'm stuck implementing a proper fall-back implementation for it since the signals don't work properly in the Mono bindings. [22:31] that is, they don't work at all [22:32] but there is a working patch attached to bug #518171 [22:32] Launchpad bug 518171 in banshee (Ubuntu) (and 1 other project) "Support Application Indicators (affects: 2)" [Wishlist,In progress] https://launchpad.net/bugs/518171 [22:34] * RAOF should probably do some libappinidcator CLI policy gardening. At some point. [22:38] RAOF: I didn't add a menu item to the tray context menu for summoning Do. Do you think that's necessary now you can't summon it by clicking on the icon? [22:39] Possibly. [22:39] To be honest, I don't use the notification icon, and I don't think it's terribly useful. [22:39] neither do I [22:39] I think it's really a (poor) work-around for a number of other problems. [22:40] I'll add a SummonMenuItem in case someone's keybindings stopped working. [22:40] top or bottom of the menu? [22:40] Top; it's the most important action you could take? [22:41] agreed [22:42] I'd love to get some design feedback on Do at some point, actually. There's a really sharp learning curve at the very start which it seems a number of users never climb. [22:42] Maybe some overlay with shortcuts and large arrows at the first run would help. [22:43] A first-run tutorial has been partially implemented, yeah. [22:44] good [22:55] qense: banshee is releasing today. I think you should try to get that patch polished asap before it's too late [22:55] qense: I am guessing the next point release will be the last chance [22:56] jcastro: I'm working on it, but I was stuck today and had enough of it. :P Now I'm polishing the GNOME Do patch after RAOF kindly pointed me at what I was doing wrong. [22:56] which made me happy again [22:56] awesome [22:57] qense: have you asked abock or gabaug to look at it yet? [22:57] jcastro: gabaug already reviewed the patch upstream and he came with a few points. [22:57] I'm now working on getting a proper fallback implementation, but the signals don't work in Mono, so that needs to be solved first. [22:58] awesome, thanks for working with them up there [22:58] qense: they're good people, glad you're working with them [22:58] they're very helpful indeed [22:59] It's also out of self interest I'm working on this. I'm using Banshee myself and I want the applications I use to behave properly. ;) [23:01] jcastro: I'll finish the GNOME Do work and then I'm off for today. I hope to fix Banshee tomorrow, but I can't promise anything, it depends on how nice libappindicator-cil decides to be. [23:01] qense: I don't mean to come off like I am pressuring you [23:01] just pointing to the clock. :D [23:02] I appreciate all you've done for this project so far! [23:02] I don't feel like being pressured. :) [23:02] thank you! [23:11] Given a GtkMenu object, can I remove a MenuItem from it, or do I have to rebuild the menu from scratch? [23:15] jcastro: qense: one of you should have approached one of the do crew, we'd have happily updated Do for libappindicator-cil [23:15] lamalex: I'm working on it right now. Everything's going great and it's almost ready. Apart from the fact that it currently kills the X server... I must have done something wrong. [23:15] haha [23:16] lamalex: I didn't know he was looking into Do until just now. [23:16] that's a pretty intense bug [23:16] hah, awesome [23:16] jcastro: I'm blaming you anyway [23:16] :P [23:16] It was working until I added an extra menu item for summoning Do [23:16] lamalex: YEAH! [23:17] qense: Ah, yeah. That's likely to run into interesting issues. [23:17] Now that I think of it... [23:18] Because we take a keyboard & pointer grab, and do it on the GTK thread, and this can make things... difficult. [23:22] I've connected the Summon Do menu item to the OnActivated function, which doesn't do much more than call "Services.Windowing.SummonMainWindow ();". Could that be related to the issue? [23:22] be the cause of* [23:22] there should be a dbus call you can make to summon [23:23] I'll look into that then [23:23] org.gnome.Do.Controller.Summon() [23:24] that should do all of the necessary pointer grabbing and so on [23:24] ok, thanks [23:24] lamalex: But this is in Do's process, in Do.Platform.Linux; it should be easier to actually summon from code, right? [23:24] oh, right [23:24] qense: It can be a bit narky if you haven't already dismissed the menu. I'd make sure that you explicitly dismiss the menu before trying to summon. [23:24] I mean, does that need to be in the menu at all? [23:24] there's the important question [23:25] It's going for feature-completeness as compared to the current notification icon; currently, clicking on the notification icon summons Do. [23:25] RAOF: I didn't add a menu item to the tray context menu for summoning Do. Do you think that's necessary now you can't summon it by clicking on the icon? [23:25] Possibly. [23:25] To be honest, I don't use the notification icon, and I don't think it's terribly useful. [23:25] maybe we should just ditch the whole notification icon [23:25] that's also an option :) [23:25] all it's got that is useful is the donate link [23:25] and I'll just put that into the dutorial :P [23:25] that you can make a donation by searching for "donate" [23:26] I'd be down with that. I hope to make it more useful in Do 1.0, but for the moment it's really a “Do hasn't crashed! Yay!” button. [23:26] yah [23:26] we mostly had it to use for notification positioning in the pre-notify osd days [23:26] and it's lingered around [23:27] We still want to support non-notify OSD, so at least having the pre-notify notification icon might be worthwhile. [23:27] you can't position on the appind icon [23:27] Yeah, but people with the app-ind probably have notify-osd, which you can't position *anyway*. [23:28] right [23:28] Just leave it in and disable it by default? [23:29] I was thinking of leaving “you're using a notification-daemon that supports positioning? Great, we'll pop up a status icon and position the notification against it” code in there. [23:29] And removing the “display notification icon” option in preferences. [23:29] I was about to suggest the same [23:29] +1 from me [23:30] so no appindicator support for Do? [23:32] well, none of this will be ready for lucid [23:32] so if you want to patch ubuntu's, fine by me [23:32] but I don't think it'll make it into upstream [23:32] since we're ditching the notification icon anyway [23:32] ok [23:32] I'll keep that throwaway branch around, though, because my perfect Do includes a use for app-indicators. [23:35] +1 for throwing away the icon anyway [23:36] Suggestion: generate a patch from ROAF's branch since that doesn't include all kind of autotools stuff Ubuntu doesn't need anyway and use that for Lucid, dumping the icon in a later release of Do? [23:40] qense: That would work. [23:42] jcastro, lamalex? [23:42] huh? [23:42] i'm a nihilist dude, I don't care [23:42] ok [23:42] RAOF: what branch is this/ [23:43] qense: whatever they say. :D [23:43] lamalex: lp:~raof/do/throwaway-app-indicators [23:43] ah [23:44] lamalex: I hope you're an *awesome* nihilist like in The Big Labowski. [23:47] RAOF: I'll generate a patch tomorrow and submit it to the Ubuntu bug report and close the upstream GNOME Do task as Won't Fix. Is that OK with you? [23:47] qense: Yes. Thanks for your work! [23:47] I'm happy to be able to contribute my share [23:47] now, off to bed1 [23:47] ! [23:48] bye