[14:06] <Nafai> Good morning!
[14:07] <seb128> hi Nafai
[14:07] <Nafai> Hey seb128, how's it?
[14:08] <seb128> good!
[14:08] <seb128> you?
[14:09] <Nafai> pretty good, finally getting back to my normal morning routine, had a hard time getting up there for a while :)
[14:17] <jcastro> Nafai: it's nice to see the bluetooth icon in the right place!
[14:17] <Nafai> Yay!
[14:18] <jcastro> mpt: on the staggered icons and whatnot, for example the bluetooth one looks just plain odd
[14:18] <jcastro> should we just remove the icons from the menu?
[14:18] <jcastro> and like, on g-p-m having the battery icon in the menu doesn't make sense either
[14:19] <mpt> jcastro, screenshot? I don't have a bluetooth card
[14:22] <seb128> jcastro, I think it's a ted bug?
[14:23] <seb128> jcastro, the appindicator menus don't respect the show_icon flag correctly
[14:23] <seb128> or always display those for stock items or something
[14:23] <seb128> like rhythmbox next, previous, exit
[14:23] <seb128> the preferences one is probably similar
[14:24] <jcastro> https://dl.dropbox.com/u/5720/weird-bt.png
[14:24] <jcastro> yeah
[14:24] <Nafai> That's what I've seen
[14:24] <jcastro> I just think they look unprofessional
[14:24] <mpt> jcastro, yeah, neither of those icons should be there
[14:24] <jcastro> ok
[14:25] <Nafai> Is there something  I need to do in the code?
[14:25] <Nafai> Or is this a library issue?
[14:25] <seb128> I think it's a lib issue
[14:25] <seb128> check with ted when he's there
[14:25] <Nafai> ok
[14:26] <jcastro> Nafai: if it's relatively easy I think we should do it
[14:26] <jcastro> I mean, that arrow(!) is just dumb
[14:27] <Nafai> Yeah
[14:27] <jcastro> "Send files to device, and here's an arrow pointing to some whitespace."
[14:28] <jcastro> mpt: I assume you feel the same way about the extra battery icon in g-p-m?
[14:28] <mpt> jcastro, oh, was g-p-m ported?
[14:29] <mpt> I thought that was an incomplete implementation of the power menu...
[14:29] <jcastro> no, we don't have a power menu
[14:29] <mpt> bbiab (30 min), in a user testing session right now
[14:30] <seb128> mpt, I told you about that the other day but you probably missed the comment ;-)
[14:31] <Nafai> jcastro: I'd have to do some special casing with some #ifdef's in the main bluetooth-applet code where the menus are built, but I could do it there
[14:31] <seb128> what are you talking about?
[14:32] <Nafai> removing the icons from the bluetooth application indicator
[14:32] <Nafai> menus
[14:32] <seb128> didn't we just say that having those is a lib bug?
[14:33] <jcastro> seb128: ok so you are saying he can just turn icons off in one place?
[14:33] <jcastro> also, there doesn't seem to be enough space after a checkbox
[14:33] <seb128> well I say they are handled as any other menu icon
[14:33] <seb128> they respect the don't show icon flag or should
[15:17] <jcastro> Nafai: ok so for Vino pitti wants an upstream review, so I guess all you need to do there is attach it the gnome bug?
[15:17] <jcastro> https://bugzilla.gnome.org/show_bug.cgi?id=606419
[15:17] <ubot4> Gnome bug 606419 in Java Client "Support for application-indicators/StatusNotifierIcon" [Enhancement,Unconfirmed]
[15:18] <jcastro> Nafai: that leaves brasero: https://bugs.edge.launchpad.net/ubuntu/+source/brasero/+bug/497853
[15:18] <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Fix committed]
[15:18] <Nafai> Yup, I'm almost done with that one
[15:18] <jcastro> I think we should have assigned that one to the desktop team?
[15:18] <Nafai> That patch isn't final
[15:18] <jcastro> I think we assigned that one when we were still just assigning them to ken
[15:18] <jcastro> ok
[15:18] <Nafai> Yeah, as soon as I get the final patch, I'll assign it to the team
[15:19] <Nafai> And I need to pass the gnome-bt patch upstream today as well
[15:19]  * jcastro nods
[15:19] <jcastro> do you think we can get both done today?
[15:19] <Nafai> Yeah, definitely
[15:19] <jcastro> \o/
[15:22] <jcastro> tedg: got time to talk about this icon staggering bits in the app indicators?
[15:22] <tedg> jcastro: Sure, not too much to talk about.
[15:23] <jcastro> so like check this out: https://dl.dropbox.com/u/5720/weird-bt.png
[15:23] <jcastro> can't we just shut off all the icons?
[15:25] <tedg> jcastro: Sure, that's in the gnome-bt patch though.
[15:25] <Nafai> What do I need to do there?
[15:25] <tedg> Nafai: Just remove the icons from the menu items.
[15:27] <Nafai> So currently, some of them are set via properties in a .ui file.  Should I just set the icon-name property at runtime to "" ?
[15:28] <jcastro> tedg: also, is it me or is there not enough space between the checkbox and the text?
[15:29] <Nafai> jcastro: I'll add that to my list for today too :)
[15:29] <jcastro> ok
[15:30] <jcastro> jpetersen: I think we should remove the extra battery icon from the g-p-m dropdown too
[15:30] <jpetersen> jcastro, yes ok
[15:30] <jcastro> tedg: when the icons get removed the text looks properly justified right?
[15:32] <tedg> Nafai: Yes, just remove the property.  No need to set it to "".
[15:32] <tedg> jcastro: Yes.
[15:32] <jcastro> tedg: dumb question - why not just have the thing not draw icons?
[15:32] <jcastro> I mean, I know it's one of the supported things
[15:33] <jcastro> but gnome is removing icons from menus anyway ...
[15:33] <tedg> jcastro: No, they're not.  They're only using them in specific cases.  And we need to support those cases.
[15:33] <jcastro> ok
[15:33] <tedg> jcastro: Look at something like the Me Menu.  The status icons look really nice there :)
[15:34] <jcastro> I am not worries about the me-menu, I know that will look good
[15:34] <jcastro> I am concerned for a 3rd party developer who doesn't know the nuances and gets stagger-city
[15:35] <Nafai>  perhaps a parameter to app_indicator_new of whether or not to use icons?
[15:36] <tedg> jcastro: In my experience, limiting it will not produce better applications.  Teaching is all that will produce better applications.
[15:36] <jcastro> fair enough
[15:37] <tedg> jcastro: You should blog about it.  We've already got the academic explanation from mpt, perhaps something from someone who only cares about staggered menus looking bad would explain it to a different set of people in a way that they'd understand.
[15:37] <jcastro> tedg: good idea. Can we have a quick call after lunch? I need you to explain the whole thing to me so I can understand it better
[15:37] <jcastro> we'll go over some talking points, etc. ?
[15:38] <tedg> jcastro: Uhm, okay.  I'm running around Dallas today.  Are you busy now?
[15:38] <mpt> jcastro I could talk with you about that if ted's busy
[15:38] <jcastro> if we could talk now that would work for me
[15:39] <tedg> davidbarth: Are you using your conference line?  Could jcastro, mpt and I use it if not?
[15:40] <mpt> jcastro, unfortunately I'm tied up in the hackfest sum-up for the next half hour or so
[15:40] <jcastro> ok I'll bother ted
[15:40] <tedg> mpt: In 50 minutes?  Half past the hour?
[15:41] <mpt> tedg, 20% probability
[15:41] <tedg> mpt: Haven't you guys talked enough? ;)
[15:41] <mpt> tedg, we're going to be subjected to a presentation of this stuff: http://blogs.gnome.org/seth/2010/02/26/let-the-wild-rumpus-begin/
[15:43] <tedg> mpt: Ah, nice.  I think users believe they needed more "poopers" in their computer.
[15:43]  * tedg has always thought we had too few
[15:44] <artir> mpt: were you at the UX meeting?
[15:45] <mpt> artir, yes, it's winding up now
[15:46] <artir> the planned design changes to the desktop are covered by the post or there are even more?
[15:47] <artir> because he promised yesterday that the design would be awesome^cool and what he posted today isn't that great
[15:50] <sanderqd> artir: i think this is still 'only' one proposal, inspired by the problems discussed (but i wasn't there)
[15:51] <artir> I'll wait for more summaries to be posted
[15:51] <artir> because he was really really excited about the designs shown there
[15:51] <artir> GNOME team's ideas to improve window management and desktop control "may amount to a bigger improvement in deep interactions with the UI than any desktop OS in the last decade can boast."
[15:51] <artir> he claimed THAT
[15:52] <artir> and i went O_O what can be that great?
[15:52] <sanderqd> isn't that related to the current gnome-shell design? that has some new interaction stuff
[15:52] <artir> yep
[15:52] <artir> gshell is nice
[15:52] <artir> it still need polish but it works
[15:57] <Nafai> jcastro: Just to verify, priorities for today: fixing icons on gnome-bt, pushing it upstream for review, pushing vino patch upstream for review, finishing brasero patch and attaching to launchpad bug, and last, finishing with rodrigo's requested changes for gnome control center and pushing to github
[16:02] <jcastro> Nafai: vino, brasero, gnome-bt, gnome-cc in that order
[16:02] <jcastro> the last 2 are already in the distro so the icon thing is just a fix
[16:02] <jcastro> I am more concerned about getting the first 2 in the distro
[16:03] <jcastro> mpt: ok so Ted just explained to me a bunch of stuff, however we should talk today when you're done with the UX sprint so that I am clear on how we want to communicate these parts.
[16:04] <jcastro> jpetersen: should I file a bug about removing that battery icon or are you just going to TODO it?
[16:05] <jpetersen> jcastro, you can file a bug so I have something to attach the patch too :)
[16:05] <jcastro> ah, good idea
[16:06] <Nafai> jcastro: cool, thanks
[16:09] <jcastro> Nafai: I'll file a bt bug too
[16:16] <davidbarth> tedg: i'm done with the call, you can use it sure
[16:17] <tedg> davidbarth: Ah, cool.  I just called jcastro already.  We're good.  Thanks!
[16:19] <jcastro> tedg: we wanted the quit icon gone from RB too right?
[16:19] <tedg> jcastro: yes.
[16:24] <jpetersen> jcastro, what is with the previous/next icons in rhythmbox?
[16:24] <jcastro> keep those
[16:26] <jcastro> jpetersen: when I talk to mpt later I'll find out what to do about those, but that will likely be past end-of-day for you
[16:26] <jpetersen> jcastro, ok :)
[17:01] <mpt> jcastro, I really think it's not a good situation that we have gnome-power-manager ported, without tooltip, and the power menu not implemented
[17:02] <mpt> jcastro, because the g-p-m tooltip is (was) the only thing that says the most important information, how many hours/minutes you have left
[17:05] <jcastro> mpt: I don't really make the determination on what gets ported or not
[17:05] <jcastro> mpt: I don't know who makes that decision
[17:08] <mpt> ok, I'll see if I can find out
[17:11] <seb128> mpt, can we have this information in the menu as label?
[17:12] <mpt> seb128, yep, that's what I specced for https://wiki.ubuntu.com/PowerStatusMenu#Design
[17:13] <seb128> mpt, should be easy to do
[17:15] <jcastro> seb128: so just a label or all the "X (estimating)" entries?
[17:15] <seb128> jcastro, I'm not a designer but I would say that should work
[17:16] <jcastro> jpetersen: on that design page how much work would it be to implement the label things under "Items"?
[17:49] <seb128> tedg, how come menus are empty if you don't gtk_show them now
[17:50] <seb128> tedg, is that a bug on your side?
[17:53] <jcastro> Nafai: how are they coming along?
[17:55] <tedg> seb128: I don't think so... I think it's just that we're looking for visibility now.
[17:55] <tedg> seb128: We need that, otherwise you gtk_widget_hide them.
[17:56] <tedg> seb128: Though, I'd agree that hide by default sucks.  I don't like that in GTK.
[17:56] <seb128> tedg, well it's different from notification area icon
[17:56] <tedg> ?
[17:56] <seb128> like the nautilus patch is minor change
[17:56] <seb128> it worked
[17:56] <tedg> Oh, because the menus are shown on click.
[17:56] <seb128> and now the menu is empty
[17:56] <seb128> I will need to add a gtk_show
[17:56] <seb128> which is not that in the notification area code version
[17:57] <tedg> Well, it is, you just don't see it as it's in popup.
[17:58] <Nafai> jcastro: Not bad.
[17:58] <Nafai> I saw the bug you assigned to me
[18:05] <seb128> tedg, I think I'm trying to argue that you should do the show for us :p
[18:05] <seb128> tedg, ie that default should be visible
[18:06] <tedg> seb128: Hmm, I don't have an issue in theory.  But, I'm worried that it'd be different that "standard GTK" which worries me.
[18:07]  * tedg is so worried he mentioned it twice to mess up his sentence...
[18:07] <seb128> lol
[18:07] <Nafai> jcastro: As far as the upstream vino bug goes, it needs to be changed to the "server" component
[18:07] <seb128> tedg, ok, let me do the gtk_show change then, will be easier for now
[18:07] <jcastro> ah, do you have perms to do that or should I?
[18:09] <jpetersen> jcastro, the labels should not be too much work, the information is already present, just need to be formatted correctly
[18:09] <Nafai> Yes, it doesn't seem like I have perms: https://bugzilla.gnome.org/show_bug.cgi?id=606419
[18:09] <ubot4> Gnome bug 606419 in Java Client "Support for application-indicators/StatusNotifierIcon" [Enhancement,Unconfirmed]
[18:11] <magcius> hmm
[18:11] <magcius> it looks like UNR EFL uses a Cairo backend for Evas, is that right?
[18:14] <jpetersen> jcastro, I oculd do it on monday
[18:15] <jcastro> mpt: seb128: what do you guys think? We could just add the labels
[18:15] <seb128> jcastro, I'm not a designer but +1
[18:16] <qense> hello everyone!
[18:16] <jcastro> hi qense!
[18:18] <jpetersen> jcastro, https://wiki.ubuntu.com/PowerStatusMenu#Design shows the menu items with icons. Should we have icons or not?
[18:19] <jcastro> jpetersen: let's see what mpt says.
[18:19] <jcastro> jpetersen: I am not sure if we are supposed to modify g-p-m to look like this or if someone is supposed to write a new thing like we did for the sound and me menus
[18:20] <jpetersen> jcastro, I do not see a reason why to not modify g-p-m
[18:21] <jcastro> hmm, he's gone for the weekend.
[18:21] <jcastro> jpetersen: on monday do the text labels and I guess we'll ask about the icons
[18:21] <jcastro> "A total of 97 icons are needed, though 33 of these may be covered by only three distinct graphics (leaving a total of 67), and 60 others consist of 30 pairs that differ only in coloring.
[18:21] <jpetersen> jcastro, it seems to be less work to adapt the design of the g-p-m application indicator than to write it from scratch
[18:22] <jcastro> I am willing to bet that they don't have 97 icons.
[18:22] <jcastro> (the art team)
[18:23] <jpetersen> jcastro, ok
[18:23] <jpetersen> sounds good
[18:23] <Nafai> jcastro: Check out my text along with my patch on the gnome bug for vino and let me know what you think
[18:25] <jcastro> Nafai: ok, let's see what Jonh says!
[18:25] <jcastro> text looks good
[18:25] <Nafai> :)
[18:25] <Nafai> Thanks
[18:29] <qense> I think I've almost sorted the Mono bindings for AppInd out, when they work properly it all depends on Banshee how quicly I can get a patch that is acceptable by upstream.
[18:29] <jcastro> \o/
[18:29] <Nafai> qense: YAY!
[18:29] <qense> don't cheer too early! ;)
[18:33] <qense> I had to learn GAPI first before I could find out what was wrong with the generation of the bindings, but thanks to the wonderful people in #mono and #monodev they now work better than ever. I wrote most of the code for Banshee already, but I threw away some of the old code that didn't work with the (somewhat) broken bindings but what is now the best approach.
[18:33] <qense> it turned out that all my work on getting the signals to work wasn't necessary for Banshee after all
[18:37] <jcastro> nice
[18:38] <qense> I'm learning a lot here. :)
[18:44] <jcastro> Nafai: ok so you're on brasero now right?
[18:45] <Nafai> Yeah
[19:03] <qense> Argh. The latest Banshee depends on Taglib 2.0.3.5, which isn't even shipped in Debian unstable yet.
[19:05] <jpetersen> have a nice weekend :)
[19:53] <jcastro> Nafai: hey are your rhythmbox next/prev dropdowns grayed out?
[19:53] <jcastro> I thought we fixed that
[19:53] <Nafai> Let me check
[19:53] <Nafai> Yeah, they are grayed out
[19:54] <seb128> jcastro, are you playing?
[19:54] <seb128> jcastro, works there
[19:55] <seb128> jcastro, did you restart your session today?
[19:55] <seb128> jcastro, it has been fixed yesterday night
[19:55] <Nafai> Yeah, I haven't restarted my session yet
[19:56] <seb128> you can restart the service and applet too
[20:04] <Nafai> lunch
[20:59] <qense> tedg: I know what's bringing the Mono bindings into problems: the status and category are assigned using their nick and not their type value. Mono expects their value to be their type, but they aren't. That's what causing all the problems.
[21:00] <qense> Why did you chose to use the nicks?
[21:00] <qense> or, at least the category is doing that
[21:01] <qense> the gobject property of the category
[21:01] <qense> which is the most important thing for the Mono bindings
[21:02] <qense> things like           enum_value = g_enum_get_value ((GEnumClass *) g_type_class_ref (APP_INDICATOR_TYPE_INDICATOR_CATEGORY), priv->category);
[21:02] <qense>           g_value_set_string (value, enum_value->value_nick);
[21:02] <qense> they're really annoying for the bindings, actually
[21:04] <qense> ah, tedg isn't here
[21:04] <qense> DBO: Did you write the initial Mono bindings for AppInd?
[21:04] <DBO> qense, initially yeah
[21:05] <DBO> have not had time to touch or update them since then
[21:05] <DBO> kind of sad really
[21:05] <qense> DBO: I'm working on getting them into shape right now and ran into a problem in the way the C libraryw as designed.
[21:05] <qense> DBO: Did you read my rant above?
[21:05] <DBO> no
[21:05] <DBO> give me the short short version
[21:05] <qense> ok :)
[21:06] <qense> Everything would be working perfectly if they would have stored the status and the category as AppIndicatorStatus and AppIndicatorCategory, but they are stored as const gchar *, mostly generated from their nick.
[21:06] <kklimonda> hmm.. can I set an IM status using me menu?
[21:06] <kklimonda> or is it only for gwibber?
[21:06] <qense> kklimonda: IM and Gwibber
[21:06] <qense> and Ubuntu One
[21:07] <qense> DBO: Rewriting it to let the library use the proper type would be the best, but I'm not sure if that's acceptable by them. I don't know the reason behind using a const gchar *
[21:07] <kklimonda> qense: but does the text entry that is present in the me menu sets both IM status and gwibber one?
[21:08] <qense> kklimonda: the text field is for sending something to your social services.
[21:08] <qense> So, Gwibber
[21:08] <kklimonda> then it is confusing as it's over the status icons :/
[21:08] <DBO> qense, I'll talk to ted
[21:09] <qense> DBO: my AppInd integration for Banshee is stalled by it :)
[21:09] <qense> not that I want to put pressure on you...
[21:09] <qense> DBO: thanks
[21:09] <DBO> no its okay if you want to put pressure on me
[21:09] <DBO> i would only be upset if you wanted to put undue pressure on me
[21:12] <qense> I would say it is a bit due, Banshee 1.6.0 will be released on march 31th, but I would like to get it into 1.5.5, due at 10 March, so it can get some proper testing
[21:18] <qense> DBO: Can you send custom types through DBus? That could be the reason since e.g. the nick string of the status is converted back to an AppIndicatorStatus type by the indicator-application service.
[21:19] <DBO> you can send standard types and structs of standard types
[21:19] <DBO> everything gets converted into and out of that
[21:20] <qense> automatically?
[21:30] <qense> DBO: I'll try to push a branch that works without those variables converted to strings.