[00:57] <jcastro> Nafai: ! Response on gnome-bt!
[00:57] <jcastro> Nafai: but that can wait for another day. <- EOD, cya tomorrow
[01:08] <Nafai> Yeah, noticed, nice to have great feedback to help me become a better programmer
=== magcius_ is now known as magcius
=== magcius is now known as magcius_
=== magcius_ is now known as magcius
=== rgreening_ is now known as rgreening
=== MacSlow is now known as MacSlow|lunch
[13:57] <jcastro> seb128: ok, smithj responded, you can toss him some bugs
[13:58] <jcastro> he says "anything"
[13:58] <jcastro> seb128: I would assign non-time critical bugs since he's part timing
[13:59] <djsiegel2> seg|ars: hi
[14:03] <jcastro> jpetersen: you saw hughsie's review of the gpm patch I take it?
[14:04] <seb128> jcastro, hey, ok
[14:06] <jpetersen> jcastro, yes I will answer him
[14:35] <Nafai> jcastro: Heading to a quick checkup with my doctor and I'll be back at around 10:30ish my time.  I
[14:35] <jcastro> cool!
[14:35] <Nafai> will take a look at the feedback on gnome bluetooth then
[16:35] <seg|ars> djsiegel2: what's up?
[16:37] <Nafai> back
=== MacSlow|lunch is now known as MacSlow|capoeira
[17:19] <kklimonda> tedg: bug 547072 - should the -panel be appended to both icon_name and attention_icon_name when they are set by the application or should it be done in app_indicator_get_icon? The code seems to be used only be the fallback anyway
[17:19] <ubot4`> Launchpad bug 547072 in indicator-application (Ubuntu) "Fallback should try to use icons with -panel suffix first, just as indicator-application does (affects: 1)" [Low,Triaged] https://launchpad.net/bugs/547072
[17:29] <kklimonda> and what are the official code standards for indicator-application? I see part of code following GNU style, some parts ~Linux style. :)
[17:29] <tedg> kklimonda: Hmm, I'm not sure if we should use -panel there or not...  it seems like if someone isn't using app indicators they wouldn't want to use our panel naming as well.
[17:29] <tedg> kklimonda: None, my coding standard is "readable" :)
[17:31] <kklimonda> tedg: hmm.. but appending -panel in the indicator-application code would be transparent for developers and we could still use themed icons.
[17:31] <kklimonda> tedg: right now rhythmbox uses rhythmbox-notplaying and rhythmbox icons
[17:32] <kklimonda> the first one have a monochromatic version and the second one does not but there is a rhythmbox-panel which is used by the indicator-application
[17:33] <kklimonda> tedg: ah, but other developers apparently believe that other style is more readable :)
[17:34] <tedg> kklimonda: Yeah, I'm just trying to figure out what would be "least surprise" -- it seems like "fallback" is don't use anything new, eh?
[17:35] <tedg> kklimonda: Yes, and they're wrong ;)  No, I just don't care that much, I think people spend too much time worrying about formatting their code and not enough time making it actually good code :)
[17:36] <kklimonda> well, that's true but using both styles in a single file looks weird and it made me confused. :)
[17:37] <kklimonda> i'd say that if we decided to use mono icons in Ubuntu then we should use them for both indicator and notification area
[17:38] <kklimonda> I don't see it as something new - rather as a theming decision.
[17:39] <kklimonda> if people aren't happy with theme they can change it but as long as they use it we should make sure that applications use it regardless of whether they use indicator or fallback to notification area.
[17:40] <kklimonda> and the current situation is broken anyway as can be seen on the screenshot :)
[17:49] <qense> jcastro: I haven't been able to find a good way for making the Banshee.AppIndicator extension conflict with Banshee.NotificationArea. There are two options to do it, but I'm not sure if any of them is something preferable: 1: make the Banshee.AppIndicator extension disable the Banshee.NotificationArea plugin from the initialisation code (nasty solution), 2: change the enabled extensions in the postinst and postrm scripts of the packaged extension.
[17:50] <Nafai> qense: I imagine Mono doesn't use a pre-processor when compiling, does it?
[17:50] <kklimonda> qense: the second solution sounds even nastier to me.. :/
[17:50] <Nafai> That's the tactic I've taken with the C ones
[17:51] <kklimonda> qense: I think that debian policy is really strict about packages changing configuration of other packages in postinst/postrm
[17:51] <qense> Nafai: It does, but we've decided to move the AppInd plugin to a separate extension in the Banshee Community Extensions project, which means we cannot mess with the 'core' plugins.
[17:51] <Nafai> ah, makes sense
[17:54] <tedg> kklimonda: Okay, I can see that.  If nothing else, it should be transparent to applications.
[17:55] <qense> dinner time, afk!
[18:02] <djsiegel2> seg|ars: here yet?
[18:03] <seg|ars> djsiegel2: yeah, what's up?
[18:24] <jcastro> Nafai: sweet, brasero response
[18:24] <Nafai> yeah, saw that, but I wonder if he looked, because it's messy and it was one of the ones I wanted to do better :)
[18:27] <jcastro> Nafai: yeah let's hope it's not "rewrite the whole thing!"
[18:27] <jcastro> Nafai: was bastien's feedback useful?
[18:28] <Nafai> yeah, most of it, though I need to point out that I can't put all of it in notify.c as he requests because the GtkStatusIcon is created and initialized in another file
[18:28] <Nafai> but the rest is helpful
[18:33] <kklimonda> tedg: do you know the reason why why setting PROP_ICON_NAME doesn't call app_indicator_set_icon but PROP_ATTENTION_ICON_NAME do call app_indicator_set_attention_icon ?
[18:33] <kklimonda> there is nothing in code, the only difference is check_connect call
[18:34] <tedg> kklimonda: Hmm, not off hand.  Seems like a bug.
[18:34] <kklimonda> tedg: it setgs the self->priv->icon_name by hand
[18:35] <tedg> kklimonda: Yeah, one place sounds better.
[18:35] <qense> jcastro: Did you read my ping above, or did it get lost in the conversation that followed it?
[18:37] <jcastro> qense: ah just noticed it
[18:37] <jcastro> I have no idea
[18:38] <jcastro> maybe DBO might be able to help?
[18:38] <qense> jcastro: Unfortunately DBO is offline atm, so that will have to wait to tomorrow.
[18:38] <qense> but I could ask him
[18:38] <jcastro> ok
[18:38] <qense> jcastro: The other solution would be to put a warning in the extention's description and submit a merge request and wait for conflict support to be added to Mono Addins.
[18:39] <jcastro> I ignore warnings
[18:39] <jcastro> so I am for that
[18:40] <qense> jcastro: That would mean that if the plugin would be accepted for Lucid we'd have a not-very-perfect solution in the LTS>
[18:49] <kklimonda> tedg: I've requested merge, it requires my previous branch to be merged before (it compiles just fine but without g_themed_icon_new_with_default_fallbacks it won't find the right icons :) )
[18:51] <tedg> kklimonda: Cool.  At the bottom of the merge you can make a "prerequisite branch" which will show only the changes in that branch.
[18:54] <kklimonda> tedg: hmm.. that's how it works. I see. I'm going to have to read some more about how to do merges in bzr
[19:36] <Nafai> jcastro: cleaning up/organizing nautilus menus is a good idea (tm) :)
[19:41] <qense> Nafai, jcastro: agreed
[19:42] <jcastro> qense: ok sorry was distracted
[19:42] <qense> jcastro: no worries, must be a busy time for you. I've already filed a merge request for the branch at Gitorious.
[19:43] <qense> jcastro: directhex pinged me and asked me if he could take a look at the code and said it was ok.
[19:43] <jcastro> qense: yeah it doesn't need to be ideal, it is an extension that is off by default.
[19:43] <qense> jcastro: true
[19:43] <jcastro> yeah I asked him to poke you to see if you needed help
[19:43] <qense> ah! :)
[19:43] <jcastro> teamwork!
[19:44] <qense> teamwork works!
=== MacSlow|capoeira is now known as MacSlow