[01:01] <Tiibiidii> hi, i just saw the new theme, and instantly felt the window controls very very backwards.... then i read one comment on jono's blog that laments by mentioning fitt's law... then i thought: since the close windows action is often supported by a known key shortcut, but the other window actions aren't... may this be better?: to have the least useful (meaning that it's less often used and it's already backed up by a s
[01:01] <Tiibiidii> hortcut) action put in a less easily accessible position, and meanwhile promoting the other actions in the corner...
[01:02] <Tiibiidii> right now i tweaked my gconf settings to replicate the future lucid theme
[01:03] <Tiibiidii> i'll try to keep it this way for some days to see if at the end it'll continue to seem so backwards to me, or if it's instead a good idea
[01:04] <Tiibiidii> in the meanwhile, can someone point me to the reasoning that sits behind this change?
[02:23] <Nafai> jcastro: around?
[02:23] <Nafai> (I know it's late for you)
[02:29] <jcastro> Nafai: yeah
[02:29] <jcastro> what's up?
[02:29] <Nafai> Should I assign bug #497853 back to pitti or to canonical-desktop-team?
[02:30] <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] https://launchpad.net/bugs/497853
[02:30] <jcastro> pitti
[02:30] <jcastro> i'll ping him tomorrow early and see if that's what he wants
[02:32] <Nafai> ok
[04:41] <lamalex> i posted a patch for https://bugs.edge.launchpad.net/hundredpapercuts/+bug/460286
[04:41] <ubot4> Launchpad bug 460286 in empathy (Ubuntu) (and 2 other projects) "enable notifications when chat is not focused (affects: 3)" [Wishlist,Triaged]
[04:58] <vish> kenvandine: ^^
=== mpt_ is now known as mpt
=== MacSlow is now known as MacSlow|lunch
[13:46] <jcastro> seb128: woo, brasero is in!
[13:47] <seb128> jcastro, only vino left?
[13:47] <jcastro> and hplip
[13:47] <jcastro> but hplip has been through the pitti gauntlet already, needs an update
[13:47] <jcastro> smithj: ping
[13:48] <seb128> ok
[13:48] <jcastro> seb128: all that's left distro-wise is adjusting the power menu like mpt wanted and after that it's all bugfixes as they come in and getting the patches upstream
[13:49] <seb128> jcastro, good
[13:52] <Nafai> Good morning
[13:52] <Nafai> I'm going to go ahead and pass brasero and gnome-bluetooth patches upstream this morning
[13:52] <jcastro> Nafai: anything left to do on vino on your side?
[13:53] <Nafai> nope, I've already passed the updated patches upstream and attached to the launchpad bug
[13:56] <Nafai> brb
[14:03] <Nafai> back
[14:04] <seb128> hey Nafai
[14:04] <seb128> I commented on your gnome-bluetooth change
[14:04] <seb128> I think we didn't understand each other yesterday
[14:04] <Nafai> Oh
[14:05]  * Nafai looks
[14:05] <seb128> I suggested changing the menu directly
[14:05] <seb128> ie the .ui
[14:05] <seb128> not doing weird code hacks
[14:05] <Nafai> well, for the items that us stock-id, if I change it to not use stock-id, we lose translations
[14:07] <Nafai> plus, if I change the .ui, that makes it less acceptable as a patch to upstream, because they would still want the icons for the GtkStatusIcon as well
[14:08] <seb128> well that's why I asked you yesterday
[14:08] <seb128> is there any reason why they would want icons and we don't
[14:08] <seb128> we use the same menu is both cases
[14:08] <seb128> if icons don't look nice they should be cleaned in both cases
[14:08] <seb128> no?
[14:10] <Nafai> I'm trying to find a screenshot to see how they looked in the old one
[14:12] <Nafai> actually, in Ubuntu at least, the status icon respects the no-icon menu setting
[14:12] <Nafai> so they aren't shown anyway
[14:12] <seb128> why doesn't the indicator do that?
[14:12] <seb128> isn"t that an indicator bug?
[14:13] <Nafai> we've talked with tedg about it, and I think it is, but he also says that (and please correct me if I mis-remember jcastro) the applications should also handle that themselves
[14:14] <Nafai> From the screenshot I see on gnome.org (http://library.gnome.org/users/gnome-bluetooth/stable/gnome-bluetooth-applet.html.en), it renders fine normally
[14:18] <jcastro> I don't remember
[14:18] <jcastro> Nafai: it's like UI freeze today so it's like our last chance to get it right
[14:20] <Nafai> what's your take on this jcastro?
[14:20] <Nafai> For the record, I don't disagree with seb128, I just want to do the right thing
[14:21] <seb128> jcastro, well making the applet respect the show icon flag would be a bug fix not an ui change
[14:21] <seb128> even if side effect is to fix an ui which was buggy
[14:22] <jcastro> seb128: yeah I know, I just want to make sure we do it right today and not have this come up tomorrow, monday, etc.
[14:22] <seb128> let's wait on ted
[14:22] <jcastro> Nafai: when in doubt I always do what seb128 wants and everything works out. :D
[14:22] <jcastro> at least brasero is done, what a pain in the neck
[14:24] <Nafai> Our conversation from the other day: http://paste.ubuntu.com/388287/
[14:26] <seb128> speaking of who
[14:26] <seb128> tedg, hy
[14:26] <seb128> hey
[14:28] <tedg> Good morning.
[14:28] <seb128> tedg, so we were talking about the bluetooth indicator
[14:28] <seb128> and stock icons
[14:28] <seb128> is indicator applet not respecting the show icon option a known bug?
[14:28] <seb128> will it be fixed for lucid?
[14:29] <tedg> It's known, but I forgot about it :)
[14:29] <tedg> It shouldn't be too hard to fix.
[14:34] <jcastro> tedg: what's your schedule like today? It would be nice to get this fixed
[14:34] <jcastro> ugh, it's thursday
[14:35] <tedg> Heh, jcastro you're getting the rhythm ;)
=== MacSlow|lunch is now known as MacSlow
[14:49] <seb128> Nafai, ^
[14:59] <seb128> jpetersen, hi
[15:00] <jpetersen> seb128, hi
[15:00] <seb128> jpetersen, thanks for the rhythmbox update
[15:00] <seb128> jpetersen, it doesn't escape markers though
[15:00] <seb128> the <i></i> are displayed
[15:00] <jpetersen> seb128, hm ok
[15:00] <seb128> rather than having those words in italic
[15:00] <seb128> did it works for you?
[15:05] <jpetersen> seb128, it was not shown here
[15:05] <jpetersen> seb128, I will just test it again
[15:06] <seb128> jpetersen, thanks
[15:06] <Nafai> Ok, brasero passed upstream
[15:06] <Nafai> brb
[15:24] <hyperair> is application indicator supposed to use that much padding?
[15:24]  * hyperair really dislikes having that much padding for anything.
[15:28] <jpetersen> seb128, ah ok I can reproduce that problem, I will fix it
[15:29] <Nafai> hyperair: You mean between icons?
[15:29] <seb128> jpetersen, thanks!
[15:37] <seb128> Nafai, so if ted fixes the show icon issue, is there anything left to change in bluetooth?
[15:39] <Nafai> seb128: Nope.  So that should take care of #528527, nothing needs to be done with the package, right?
[15:40] <hyperair> Nafai: yes, between the icons.
[15:41] <seb128> Nafai, ok, what I think too, good ;-)
[15:42] <Nafai> so I'll go ahead and pass the existing patch (the one already packaged) upstream
[15:43] <seb128> Nafai, thanks
[15:54] <Nafai> seb128: I actually was just reviewing your comments to the original bug for app indicator support and noticed I had forgot to change this to APP_INDICATOR_CATEGORY_HARDWARE
[15:54] <Nafai> I should probably do that and double check the other things were done
[15:54] <seb128> ok
[15:54] <Nafai> I've got a call here in a few minutes, but I can quickly make those changes after
[16:01] <tedg> hyperair: There is supposed to be more than in the notification area, but I'm worried that I might have too much currently.  I haven't investigated though.
[16:01] <tedg> hyperair: I think something might be getting padded twice.
[16:02] <hyperair> tedg: i see. what's the padding for?
[16:02] <hyperair> tedg: isn't the notification area cluttered enough without padding stretching it even wider?
[16:02] <tedg> hyperair: Just to make it easier to hit the items.  And to make them look nice.  (probably more the second)
[16:02] <hyperair> heh
[16:02] <hyperair> alright
[16:03]  * hyperair will need to undergo panel appletsectomy after upgrading to lucid
[16:03] <seb128> fedora did extra padding change previous cycle in their notification area too
[16:04] <hyperair> hmm, did they?
[16:04] <seb128> yes
[16:04] <hyperair> but they don't have appind do they?
[16:04] <hyperair> so this padding is for the notification area icon alone?
[16:04] <seb128> no
[16:04] <seb128> yes
[16:04] <hyperair> i mean notification area
[16:04] <seb128> http://blogs.fedoraproject.org/wp/mclasen/2009/10/26/5-little-things/
[16:05] <seb128> the second item on the list there
[16:05] <jpetersen> seb128, I updated the rhythmbox patch to fix the markup issues
[16:06] <seb128> jpetersen, oh, nice, looking
[16:07] <hyperair> seb128: interesting.
[16:13] <jpetersen> I will be back soon
[17:37] <qense> Is bug #528088 valid for all AppIndicators?
[17:37] <ubot4> Launchpad bug 528088 in transmission (Ubuntu) "Transmission applet does not show when there are no indicator applet (affects: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/528088
[17:39] <seb128> qense, indicator fallback to a notification area icon
[17:40] <seb128> that bug is weird
[17:40] <seb128> I usually have the opposite issue
[17:40] <seb128> I've to make sure the service is not running to have the fallback working
[17:40] <seb128> ie removing the indicator applet with the service still running breaks
[17:41] <qense> seb128: I've stumbled about your issue a few time as well.
[17:41] <seb128> but once you stop the service it works
[17:41] <qense> that's true
[17:41] <qense> the service keeps running
[17:43] <qense> seb128: It would be great if there was some way for applications to subscribe to the availability of a certain application, something like libunique, so they reliably know when something is running and when not.
[17:43] <qense> Both the service and the applet could use it.
[17:43] <qense> and probably many other applications as well.
[17:46] <seb128> qense, bug #532044 is a duplicate
[17:46] <ubot4> Launchpad bug 532044 in rhythmbox (Ubuntu) (and 1 other project) "When Rhythmbox is launched, all you see is the tray icon (affects: 1)" [Undecided,New] https://launchpad.net/bugs/532044
[17:46] <seb128> please close it
[17:46] <qense> seb128: will do, thanks for mentioning
[17:51] <Nafai>   What currently happens if you set the status to attention and there isn't an attention icon set?  Does it just stay with the ACTIVE status?
[18:11] <qense> I've dumped bug #527282 in gtk+2.0, but is that the right place for it?
[18:11] <ubot4> Launchpad bug 527282 in gtk+2.0 (Ubuntu) (and 1 other project) "GtkWindows cannot be raised, show() doesn't do the trick (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527282
[18:12] <qense> The issue is with the fact that when you press Show Window in the tray menus the show() function is used, which doesn't raise the window.
[18:12] <qense> Before AppInd you could raise the hidden windows from the tray.
[19:03] <Nafai> Okay, I just finished #532104
[19:03] <Nafai> bug #532104
[19:03] <ubot4> Launchpad bug 532104 in gnome-bluetooth (Ubuntu) "Fix app indicator classification and other minor issues (affects: 1)" [Undecided,In progress] https://launchpad.net/bugs/532104
[19:03] <Nafai> Addresses feedback seb128 gave me before that I missed
[19:05] <jcastro> Nafai: woo!
[19:05] <Nafai> If this is good, I'll pass it upstream
[19:06] <jcastro> Nafai: tomorrow I was thinking of sending the brasero and vino guys a mail
[19:06] <jcastro> if we could have a call I'd like to get some things straight
[19:06] <Nafai> K, vino has been sitting there for like a week or something
[19:06] <Nafai> sure thing
[19:06] <jcastro> explain why it's so invasive, etc.
[19:06] <jcastro> yeah
[19:07] <Nafai> pitti and I successfully used Empathy/gtalk earlier today
[19:07] <Nafai> worked well
[19:09] <jcastro> yeah it's getting much better
[19:09] <jcastro> last cycle I couldn't use it at all but it's pretty good now
[19:09] <jcastro> all it really needs is voice cancellation
[19:09] <Nafai> yeah
[19:13] <Nafai> I'm going to go grab lunch
[19:13] <Nafai> Then I'll need to figure out what's next :)
[20:07] <Nafai> back
[20:07] <Nafai> jcastro: what would you suggest I work on next?
[20:07] <jcastro> well, no outstanding bugs at the moment. 
[20:08] <jcastro> Maybe qense needs help with the banshee work?
[20:08] <jcastro> Nafai: we're at UI freeze so it doesn't really make sense to port new apps
[20:08] <Nafai> right
[20:09] <Nafai> qense: Around?
[20:09] <jcastro> seb128: anything you guys need help with?
[20:10] <qense> jcastro, Nafai: I'm around
[20:11] <Nafai> Need any help with Banshee?
[20:12] <seb128> jcastro, landing the new artwork in lucid? ;-)
[20:12] <qense> Banshee itself is not that much of a problem, I think it would be best if I would finish that myself since I've made myself acquainted with the code. However, libappindicator-cil is the real time drainer.
[20:12] <qense> seb128: Plymouth should be there already, I'm anxiously waiting for the rest!
[20:12] <seb128> jcastro, out of that nothing I can think about today no
[20:12] <jcastro> ok
[20:12] <seb128> qense, yeah I know
[20:12] <seb128> qense, wallpaper too
[20:12] <qense> yes, forgot that one
[20:12] <seb128> qense, I just uploaded the gnome-panel icon theme
[20:12] <jcastro> tedg: how are your indicator-application bugs? perhaps Nafai can lend a hand when he's not fixing the apps themselves?
[20:13] <Nafai> Yeah, I don't mind diving in
[20:13] <qense> Although I have to say that I am closing in on the Mono binding problems with AppInd.
[20:13] <Nafai> I'm not very experienced with C# or Mono, so I'd probably be less helpful with binding work
[20:13] <qense> Nafai: how much do you know of C# and GAPI?
[20:14] <Nafai> heh. :)
[20:14] <tedg> jcastro: I know of three.  The fallback thing in gpm.  The fallback on startup.  And then the python append one.
[20:14] <qense> tedg: is the transmission bug the only report about the fallback on startup?
[20:14] <qense> tedg: then I'll convert it to a more generic bug report
[20:14] <tedg> jcastro: So, I'd say that there isn't a huge problem there, but help is always appreciated :)
[20:15] <tedg> qense: That's the only one I've seen it on, but I can't imagine it's transmission only.
[20:15] <qense> tedg: I'll convert it then.
[20:15] <tedg> qense: That'd be just too weird :)
[20:15] <jcastro> Nafai: ok so see if you can help tedg 
[20:15] <Nafai> cool, thanks.
[20:15] <Nafai> tedg: Which would you like me to look at?
[20:16] <tedg> Nafai: The Python one would probably be best to start out, it's blocking apps.
[20:16] <tedg> Nafai: The others are annoyances (that should get fixed)
[20:16] <qense> jcastro: I just had a busy week, but I hope to be able to finish it this weekend. Although I have said before that Banshee was almost finished. :)
[20:16] <Nafai> Okay.  Bug # and branch to work on?
[20:16] <jcastro> heh
[20:17] <qense> atm I'm writing a blog to advertise AdoptUpstream
[20:19] <jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/indicator-application/+bug/530138
[20:19] <qense> I hope to have found a working solution for libappind-cil tomorrow so I can have a working library at least ready for personal use Saturday which means I can continue to work on the aptch.
[20:19] <jcastro> tedg: Nafai ^^^
[20:19] <ubot4> Launchpad bug 530138 in indicator-application (Ubuntu Lucid) (and 2 other projects) "Using .append() on a gtkmenu doesn't update the indicator's menu (affects: 1)" [High,Triaged]
[20:19] <qense> What about the .set_menu() crash?
[20:19] <jcastro> marc needs that bug fixed so he can finish off app indicators for virt-manager
[20:29] <Nafai> tedg: Is this the branch I should base upon? https://code.launchpad.net/~indicator-applet-developers/indicator-application/lucid
[20:29] <tedg> Nafai: No, please use lp:indicator-application
[20:29] <Nafai> ok, thanks
[20:30] <Nafai> wee, now to figure out bzr :)
[20:31] <tedg> Nafai: All you really need is:
[20:31] <tedg> bzr branch lp:indicator-application
[20:31] <tedg> <do work>
[20:31] <tedg> bzr commit
[20:31] <tedg> <do more work>
[20:31] <tedg> bzr commit
[20:31] <tedg> bzr push lp:~nafai/indicator-application/my-fix
[20:31] <Nafai> cool
[20:31] <Nafai> I've made the mistake in the past just doing bzr checkout and finding out bzr commit doesn't work so well :)
[20:32] <qense> Nafai: bzr commit --fixes lp:{bug_number} associates a commit with a certain bug
[20:32]  * Nafai nods
[21:37] <Nafai> I think I figured out what may be going on.  GtkMenuShell.insert may not be emitting the add signal which is what the app indicator hooks up to
[21:37] <Nafai> but calling GtkContainer.add *does* emit the signal (of course), which then causes app indicators to get it
[21:38] <Nafai> I'm doing some more digging to be sure