[00:34] <Nafai> Getting closer to with vino....
[00:35] <Nafai> bbiab, getting dinner
[02:07] <Nafai> Yay for added complexity
[02:11] <Nafai> 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] <qense> MacSlow: Could you take a look at this merge request: <https://code.launchpad.net/~qense/notify-osd/fix-465801/+merge/14265>? 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] <MacSlow> qense, did you sign that?
[11:43] <qense> yes
[11:43] <qense> MacSlow: I already contributed a few lines to some other projects that require it as well
[11:44] <MacSlow> 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] <qense> MacSlow: thanks!
[11:44] <MacSlow> np
[11:44] <qense> maybe there should come a team for people who have signed so it's easier to verify
[12:36] <qense> 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] <ubot4> Launchpad bug 526620 in indicator-application "ApplicationIndicator signal names not set in C#/Mono bindings (affects: 1)" [Undecided,New] https://launchpad.net/bugs/526620
[12:45] <qense> (afk)
[13:14] <C10uD> hello, i'm trying latest lucid iso and seems like python bindings for libappindicator are still "broken"
[13:14] <C10uD> i correctly managed to update the menu in the indicator calling set_menu everytime i add/remove items
[13:15] <C10uD> but still, i cannot set the icon-theme-path property
[13:15] <C10uD> 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] <qense> (back)
[13:27] <qense> C10uD: Have you tried passing the path as the fourth argument to the constructor?
[13:27] <C10uD> maximum 3 arguments allowed
[13:28] <qense> C10uD: then I'd search for a bug report describing the issue and if you cannot find one, report it.
[13:32] <C10uD> qense, there's a similar bug, triaged by you..
[13:32] <qense> C10uD: ok, then please add your information to the report.
[13:32] <C10uD> basically that was the exact thing i needed, but here i was told to use icon-theme-path instead
[13:33] <C10uD> you already answered as "won't do it"
[13:33] <qense> C10uD: Ah, that bug report. I would file a separate bug for the Python bindings.
[13:40] <C10uD> ok, here's the bug
[13:40] <C10uD> https://bugs.launchpad.net/indicator-application/+bug/527061
[13:41] <ubot4> Launchpad bug 527061 in indicator-application "python bindings for libappindicator don't allow to change icon-theme-path (affects: 1)" [Undecided,New]
[13:42] <qense> C10uD: thank you!
[13:44] <C10uD> thank you if you fix it, i'm waiting for getting that fixed so i can release emesene with appindicator support :p
[15:05] <jcastro> qense: when ted get's on let's bug him on lp #527061
[15:05] <ubot4> 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] <nigelb> qense: you around?
[15:05] <jcastro> 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] <qense> nigelb: yes I am
[15:05] <qense> jcastro: What tag are you using?
[15:05] <nigelb> qense: need a little bit of hand with python
[15:06] <jcastro> qense: indicator-application still
[15:06] <qense> nigelb: Ask whatever you want
[15:06] <qense> jcastro: ok
[15:06] <qense> btw, tedg is already here
[15:06] <qense> tedg: could you take a look at bug #527061?
[15:06] <ubot4> 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] <jcastro> according to my calculations he should be on a call right now
[15:06] <qense> ah
[15:06] <qense> I didn't know that
[15:07] <nigelb> qense: take a look at the masking code.  I'm not sure how to do it.  http://pastebin.com/XTrQLPGD
[15:07] <tedg> qense: Yeah, I can look after my call.  But for Python stuff kenvandine is probably going to be mroe helpful.
[15:08] <qense> tedg: ok, thanks anyway!
[15:08] <seb128> hey tedg jcastro
[15:08] <seb128> jcastro, tedg: the checkbox not updating in appindicators menus issue is supposed to be fixed in lucid?
[15:09] <tedg> seb128: No, I haven't investigated what happened.
[15:09] <seb128> ok
[15:11] <qense> 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] <ubot4> 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] <qense> ahem, wrong bug
[15:11] <qense> bug #527082
[15:11] <ubot4> 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] <qense> afk, nigelb: I'll get back to you when I'm back
[15:56] <seb128> jcastro, bug #526864
[15:56] <ubot4> 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] <seb128> jcastro, can you get that one assigned?
[15:56] <jcastro> done
[15:56] <seb128> thanks
[16:04] <Nafai> Good morning
[16:04] <seb128> hey Nafai
[16:04] <Nafai> Hey seb128, how are you today?
[16:05] <seb128> Nafai, good! you?
[16:05] <Nafai> Pretty good
[16:36] <qense> I can't solve the signal problem, moving on to one of the many other things on my ToDo list.
[18:16] <jcastro> Nafai: how we feeling today?
[18:16] <jcastro> Nafai: jpetersen busted out polkit-1-gnome so we're on the homestretch now!
[18:17] <Nafai> Sweet
[18:17] <Nafai> doing well, I'm just heading to my dr's appointment, be back in a couple
[18:17] <jcastro> cool
[18:17] <jcastro> good luck!
[20:08] <Nafai> 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] <jcastro> Nafai: no worries, hope you feel better
[20:10] <Nafai> thanks
[20:32] <kklimonda> have you guys collaborated with gnome folks on their usability hackfest?
[20:32] <jcastro> kklimonda: it's hosted at the Canonical offices
[20:33] <kklimonda> well, that was the answer I was hoping to get :)
[21:35] <RAOF> Damn.  How did I miss qense *again*?
[21:36] <kklimonda> he's like a ninja ;)
[22:15] <Nafai> Ok, I'm back, feeling much better after that rest
[22:24] <RAOF> qense: Hah!  Caught you :).
[22:24] <qense> RAOF?
[22:24] <RAOF> qense: Thanks for the gnome-do application-indicator work; I've spotted your problem.
[22:25] <qense> RAOF: really! Great!
[22:25] <qense> tell me!
[22:25] <RAOF> Basically, you can't use other services is a service constructor.
[22:26] <RAOF> I've pushed up a branch of Do that works, but doesn't have any compile-time switch.
[22:26] <RAOF> lp:~raof/do/throwaway-app-indicator
[22:26] <qense> throwaway?
[22:27] <RAOF> It's a throwaway branch; it will only work with app-indicators.
[22:27] <qense> ah
[22:27] <RAOF> It just shows working app indicator code.  To do that quickly, I got rid of the GtkStatusIcon code.
[22:28] <qense> The main change is the use of IconTheme.Default.HasIcon ?
[22:28] <RAOF> Main change is moving the construction of the menu into Initialize, rather than the constructor.
[22:28] <qense> ah
[22:29] <qense> important
[22:29] <RAOF> The constructor will be called before the service stack is fully available.
[22:29] <qense> ok, that explains a lot :)
[22:29] <RAOF> Which is why you were seeing a stack overflow :)
[22:30] <qense> RAOF: Thank you very much for helping me with this!
[22:30] <RAOF> No problem.
[22:30] <RAOF> How's Banshee going?
[22:31] <qense> 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] <qense> that is, they don't work at all
[22:32] <qense> but there is a working patch attached to bug #518171
[22:32] <ubot4> 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] <qense> 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] <RAOF> Possibly.
[22:39] <RAOF> To be honest, I don't use the notification icon, and I don't think it's terribly useful.
[22:39] <qense> neither do I
[22:39] <RAOF> I think it's really a (poor) work-around for a number of other problems.
[22:40] <qense> I'll add a SummonMenuItem in case someone's keybindings stopped working.
[22:40] <qense> top or bottom of the menu?
[22:40] <RAOF> Top; it's the most important action you could take?
[22:41] <qense> agreed
[22:42] <RAOF> 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] <qense> Maybe some overlay with shortcuts and large arrows at the first run would help.
[22:43] <RAOF> A first-run tutorial has been partially implemented, yeah.
[22:44] <qense> good
[22:55] <jcastro> qense: banshee is releasing today. I think you should try to get that patch polished asap before it's too late
[22:55] <jcastro> qense: I am guessing the next point release will be the last chance
[22:56] <qense> 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] <qense> which made me happy again
[22:56] <jcastro> awesome
[22:57] <jcastro> qense: have you asked abock or gabaug to look at it yet?
[22:57] <qense> jcastro: gabaug already reviewed the patch upstream and he came with a few points.
[22:57] <qense> 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] <jcastro> awesome, thanks for working with them up there
[22:58] <jcastro> qense: they're good people, glad you're working with them
[22:58] <qense> they're very helpful indeed
[22:59] <qense> 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] <qense> 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] <jcastro> qense: I don't mean to come off like I am pressuring you
[23:01] <jcastro> just pointing to the clock. :D
[23:02] <jcastro> I appreciate all you've done for this project so far!
[23:02] <qense> I don't feel like being pressured. :)
[23:02] <qense> thank you! 
[23:11] <Nafai> Given a GtkMenu object, can I remove a MenuItem from it, or do I have to rebuild the menu from scratch?
[23:15] <lamalex> jcastro: qense: one of you should have approached one of the do crew, we'd have happily updated Do for libappindicator-cil
[23:15] <qense> 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] <lamalex> haha
[23:16] <jcastro> lamalex: I didn't know he was looking into Do until just now.
[23:16] <lamalex> that's a pretty intense bug
[23:16] <jcastro> hah, awesome
[23:16] <lamalex> jcastro: I'm blaming you anyway
[23:16] <lamalex> :P
[23:16] <qense> It was working until I added an extra menu item for summoning Do
[23:16] <jcastro> lamalex: YEAH!
[23:17] <RAOF> qense: Ah, yeah.  That's likely to run into interesting issues.
[23:17] <RAOF> Now that I think of it...
[23:18] <RAOF> Because we take a keyboard & pointer grab, and do it on the GTK thread, and this can make things... difficult.
[23:22] <qense> 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] <qense> be the cause of*
[23:22] <lamalex> there should be a dbus call you can make to summon
[23:23] <qense> I'll look into that then
[23:23] <lamalex> org.gnome.Do.Controller.Summon()
[23:24] <lamalex> that should do all of the necessary pointer grabbing and so on
[23:24] <qense> ok, thanks
[23:24] <RAOF> lamalex: But this is in Do's process, in Do.Platform.Linux; it should be easier to actually summon from code, right?
[23:24] <lamalex> oh, right
[23:24] <RAOF> 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] <lamalex> I mean, does that need to be in the menu at all?
[23:24] <lamalex> there's the important question
[23:25] <RAOF> It's going for feature-completeness as compared to the current notification icon; currently, clicking on the notification icon summons Do.
 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?
 Possibly.
[23:25] <qense>  To be honest, I don't use the notification icon, and I don't think it's terribly useful.
[23:25] <lamalex> maybe we should just ditch the whole notification icon
[23:25] <qense> that's also an option :)
[23:25] <lamalex> all it's got that is useful is the donate link
[23:25] <lamalex> and I'll just put that into the dutorial :P
[23:25] <lamalex> that you can make a donation by searching for "donate"
[23:26] <RAOF> 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] <lamalex> yah
[23:26] <lamalex> we mostly had it to use for notification positioning in the pre-notify osd days
[23:26] <lamalex> and it's lingered around
[23:27] <RAOF> We still want to support non-notify OSD, so at least having the pre-notify notification icon might be worthwhile.
[23:27] <qense> you can't position on the appind icon
[23:27] <RAOF> Yeah, but people with the app-ind probably have notify-osd, which you can't position *anyway*.
[23:28] <lamalex> right
[23:28] <qense> Just leave it in and disable it by default?
[23:29] <RAOF> 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] <RAOF> And removing the “display notification icon” option in preferences.
[23:29] <lamalex> I was about to suggest the same
[23:29] <lamalex> +1 from me
[23:30] <qense> so no appindicator support for Do?
[23:32] <lamalex> well, none of this will be ready for lucid
[23:32] <lamalex> so if you want to patch ubuntu's, fine by me
[23:32] <lamalex> but I don't think it'll make it into upstream
[23:32] <lamalex> since we're ditching the notification icon anyway
[23:32] <qense> ok
[23:32] <RAOF> I'll keep that throwaway branch around, though, because my perfect Do includes a use for app-indicators.
[23:35] <jcastro> +1 for throwing away the icon anyway
[23:36] <qense> 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] <RAOF> qense: That would work.
[23:42] <qense> jcastro, lamalex?
[23:42] <lamalex> huh?
[23:42] <lamalex> i'm a nihilist dude, I don't care
[23:42] <qense> ok
[23:42] <lamalex> RAOF: what branch is this/
[23:43] <jcastro> qense: whatever they say. :D
[23:43] <RAOF> lamalex: lp:~raof/do/throwaway-app-indicators
[23:43] <lamalex> ah
[23:44] <RAOF> lamalex: I hope you're an *awesome* nihilist like in The Big Labowski.
[23:47] <qense> 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] <RAOF> qense: Yes.  Thanks for your work!
[23:47] <qense> I'm happy to be able to contribute my share
[23:47] <qense> now, off to bed1
[23:47] <qense> !
[23:48] <qense> bye