/srv/irclogs.ubuntu.com/2010/03/25/#ayatana.txt

jcastroNafai: ! Response on gnome-bt!00:57
jcastroNafai: but that can wait for another day. <- EOD, cya tomorrow00:57
NafaiYeah, noticed, nice to have great feedback to help me become a better programmer01:08
=== 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
jcastroseb128: ok, smithj responded, you can toss him some bugs13:57
jcastrohe says "anything"13:58
jcastroseb128: I would assign non-time critical bugs since he's part timing13:58
djsiegel2seg|ars: hi13:59
jcastrojpetersen: you saw hughsie's review of the gpm patch I take it?14:03
seb128jcastro, hey, ok14:04
jpetersenjcastro, yes I will answer him14:06
Nafaijcastro: Heading to a quick checkup with my doctor and I'll be back at around 10:30ish my time.  I14:35
jcastrocool!14:35
Nafaiwill take a look at the feedback on gnome bluetooth then14:35
seg|arsdjsiegel2: what's up?16:35
Nafaiback16:37
=== MacSlow|lunch is now known as MacSlow|capoeira
kklimondatedg: 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 anyway17: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/54707217:19
kklimondaand what are the official code standards for indicator-application? I see part of code following GNU style, some parts ~Linux style. :)17:29
tedgkklimonda: 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
tedgkklimonda: None, my coding standard is "readable" :)17:29
kklimondatedg: hmm.. but appending -panel in the indicator-application code would be transparent for developers and we could still use themed icons.17:31
kklimondatedg: right now rhythmbox uses rhythmbox-notplaying and rhythmbox icons17:31
kklimondathe first one have a monochromatic version and the second one does not but there is a rhythmbox-panel which is used by the indicator-application17:32
kklimondatedg: ah, but other developers apparently believe that other style is more readable :)17:33
tedgkklimonda: 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:34
tedgkklimonda: 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:35
kklimondawell, that's true but using both styles in a single file looks weird and it made me confused. :)17:36
kklimondai'd say that if we decided to use mono icons in Ubuntu then we should use them for both indicator and notification area17:37
kklimondaI don't see it as something new - rather as a theming decision.17:38
kklimondaif 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:39
kklimondaand the current situation is broken anyway as can be seen on the screenshot :)17:40
qensejcastro: 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:49
Nafaiqense: I imagine Mono doesn't use a pre-processor when compiling, does it?17:50
kklimondaqense: the second solution sounds even nastier to me.. :/17:50
NafaiThat's the tactic I've taken with the C ones17:50
kklimondaqense: I think that debian policy is really strict about packages changing configuration of other packages in postinst/postrm17:51
qenseNafai: 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
Nafaiah, makes sense17:51
tedgkklimonda: Okay, I can see that.  If nothing else, it should be transparent to applications.17:54
qensedinner time, afk!17:55
djsiegel2seg|ars: here yet?18:02
seg|arsdjsiegel2: yeah, what's up?18:03
jcastroNafai: sweet, brasero response18:24
Nafaiyeah, 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:24
jcastroNafai: yeah let's hope it's not "rewrite the whole thing!"18:27
jcastroNafai: was bastien's feedback useful?18:27
Nafaiyeah, 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 file18:28
Nafaibut the rest is helpful18:28
kklimondatedg: 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
kklimondathere is nothing in code, the only difference is check_connect call18:33
tedgkklimonda: Hmm, not off hand.  Seems like a bug.18:34
kklimondatedg: it setgs the self->priv->icon_name by hand18:34
tedgkklimonda: Yeah, one place sounds better.18:35
qensejcastro: Did you read my ping above, or did it get lost in the conversation that followed it?18:35
jcastroqense: ah just noticed it18:37
jcastroI have no idea18:37
jcastromaybe DBO might be able to help?18:38
qensejcastro: Unfortunately DBO is offline atm, so that will have to wait to tomorrow.18:38
qensebut I could ask him18:38
jcastrook18:38
qensejcastro: 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:38
jcastroI ignore warnings18:39
jcastroso I am for that18:39
qensejcastro: That would mean that if the plugin would be accepted for Lucid we'd have a not-very-perfect solution in the LTS>18:40
kklimondatedg: 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:49
tedgkklimonda: Cool.  At the bottom of the merge you can make a "prerequisite branch" which will show only the changes in that branch.18:51
kklimondatedg: hmm.. that's how it works. I see. I'm going to have to read some more about how to do merges in bzr18:54
Nafaijcastro: cleaning up/organizing nautilus menus is a good idea (tm) :)19:36
qenseNafai, jcastro: agreed19:41
jcastroqense: ok sorry was distracted19:42
qensejcastro: no worries, must be a busy time for you. I've already filed a merge request for the branch at Gitorious.19:42
qensejcastro: directhex pinged me and asked me if he could take a look at the code and said it was ok.19:43
jcastroqense: yeah it doesn't need to be ideal, it is an extension that is off by default.19:43
qensejcastro: true19:43
jcastroyeah I asked him to poke you to see if you needed help19:43
qenseah! :)19:43
jcastroteamwork!19:43
qenseteamwork works!19:44
=== MacSlow|capoeira is now known as MacSlow

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!