#ayatana 2009-03-13 <MacSlow> morning folks <kwwii> w00t <bratsche> werd <MacSlow> yo <MacSlow> indeed <tedg> Folks, this isn't #hiphop ;) <kwwii> so watcha, watcha, watcha want? #ayatana 2009-03-16 <tedg> Hmm, does the bot do bugs too? bug 1 <mpt> tedg, had you used the append hint in pidgin-libnotify (or anything else) yet? <tedg> mpt: We're sending it, but notify-osd isn't rendering it correctly yet. <tedg> mpt: There's a bug about it, I can find it if you'd like. <mpt> tedg, are you sending "append", "canonical-private-append", or "x-canonical-append"? <tedg> mpt: "append=allow" <mpt> tedg, so you're not one but two names out of date :-) <mpt> http://pastebin.ubuntu.com/130241/ <tedg> mpt: Hmm, that kinda sucks. Why do we keep changing them? <mpt> whoops, actually only one, "canonical-private-append" wasn't used. <mpt> tedg, because I didn't read the spec properly, I'm sorry. <tedg> mpt: Perhaps we need a header file or something. <mpt> I've just added pidgin-libnotify to bug 341565. <tedg> Hmm... thanks? ;) #ayatana 2009-03-17 <kwwii> btw, if anyone sees old icons showing up in the notifications, please do mention it (or file a bug!) <mpt> kwwii, there are already eleventeen bug reports about that, can't you use one of those? :-) <MacSlow> kwwii, you mean that in general or focused on a particular app using notifications? <kwwii> MacSlow: in general <kwwii> mpt: well, pretty much all the bugs I've seen have to do with the names not being used correctly, not missing icons <kwwii> mpt: what did you search for to get that list? <MacSlow> kwwii, well the only issues with icons used in notifications I have is pidgin's use of low-res protocol-logo icons ... and the "gtk-info" icon used by epiphany's "download finished" notification <mpt> kwwii, is it the case that mt's icons should appear when you're using the Human theme, and old-timey Gnome icons should appear when you're using any other theme? <kwwii> mpt: yes <mpt> ok <MacSlow> kwwii, apart from those my "icon crispness"-experience is fine <kwwii> and those icons have been included but I am not sure if that is working right or not <kwwii> somewhat busy working on gdm and usplash and wallpaper and....atm, so testing this stuff is kinda hard <MacSlow> np <mpt> It must be nearly lunchtime, I saw "crispness experience" and started thinking of potato chips <MacSlow> mpt, :) <MacSlow> mpt, it's "icon crispness" <MacSlow> mpt, you don't want to eat those <mpt> Well, if I had a crisp icon appearing in a potato chip, I'd attract a lot of Catholics * MacSlow just grabs another gazillion package updates <mpt> http://www.sptimes.com/2005/06/08/Neighborhoodtimes/An_image_of_Jesus__Al.shtml <kwwii> I once saw yoda in some mold on cheese...guess that's not the same though <kwwii> then again, yoda plays a pretty central role in my belief system <MacSlow> Ken sees Yoda in cheese <MacSlow> uff, that takes time to settle ;) <kwwii> hey, I don't make fun of your god * MacSlow -> lunch * MacSlow takes an evening-break #ayatana 2009-03-18 * MacSlow -> lunch #ayatana 2009-03-19 * MacSlow -> lunch * MacSlow takes a break #ayatana 2009-03-20 * MacSlow -> lunch * MacSlow -> capoeira #ayatana 2009-03-23 * MacSlow -> very late lunch <MacSlow> bbl #ayatana 2009-03-24 * MacSlow -> lunch * MacSlow -> capoeira #ayatana 2009-03-25 * MacSlow -> lunch <tedg> mpt: Can we talk about time a little bit? :) <tedg> mpt: Mark had mentioned having the time in the messaging indicator be time elapsed. <tedg> mpt: I was just going to do minutes if it's minutes and hours if it's hours. Do you think it needs to be more sophisticated? <mpt> tedg, not sure, but my first thought was to show relative time for <60 minutes ago and absolute time for greater <tedg> mpt: That seems like a confusing change. I think having both would confuse me. <tedg> For sure you couldn't look at it quickly. <mpt> tedg, Nautilus has a similar switch, using relative dates for things modified today or yesterday, absolute dates for anything older. <mpt> and Thunderbird omits the day for messages received today. <tedg> mpt: The mail case isn't change the information provided, it's just changing the amount of detail. We'd be changing from relative to absolute. <mpt> sure <tedg> mpt: And in the Nautilus case they have more space to provide that distinction. They can do "4 minutes ago" where we'd be doing "3 m". <mpt> true <mpt> so for space reasons, I think it would make more sense just to stick with absolute times <tedg> For locale reasons I'd prefer to stick with relative times ;) <tedg> It solves the problem of "I prefer X type of time" which is tricky, and goes beyond locale. <tcole> there's also the issue that people think more in terms of relative time <tedg> tcole: Absolutely! ;) #ayatana 2009-03-26 * MacSlow -> lunch * MacSlow -> capoeira #ayatana 2009-03-27 * MacSlow -> capoeira-break #ayatana 2009-03-31 * MacSlow -> lunch * MacSlow -> capoeira #ayatana 2010-03-01 <C10uD> hello, i updated bug 527061 <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 <C10uD> i'm still unsure on how to test if this actually works, make&&make install the bindings doesn't produce any difference.. <jcastro> morning seb128 <seb128> hey jcastro <seb128> how are you today? <jcastro> good <jcastro> did you see Kalle ported Tracker to a-i? <seb128> no I didn't <jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/tracker/+bug/497912 <seb128> nice ;-) <jcastro> !!! <ubot4> Launchpad bug 497912 in tracker (Ubuntu) "Support Application Indicators (affects: 1)" [Low,Triaged] <jcastro> seb128: so what's the plan for g-s-d? <jcastro> polkit-1-gnome is also ready! <seb128> g-s-d relies on those libgnomekbd refactoring which neither pitti or I like to get in distro <seb128> I guess I will have to sit down and look at this one this week <jcastro> ok <jpetersen> The code could basically be moved from libgnomekbd to g-s-d <qense> kklimonda: you're afk, but you'll probably read your pings: the text field in the Me Menu also sets your IM status after all. I was wrong. <jcastro> jpetersen: whichever makes it easier to put it in the distro I would guess. seb128? <seb128> jpetersen, I've not looked at the details but your change is change the way the code is structured a bit to make easier to share code between appindicator and notification? <jpetersen> for upstream it should be in libgnomekbd but for lucid just patching g-s-d would maybe be easier <seb128> right that's what I was thinking <seb128> could you work on that change? <seb128> I would prefer a code copy rather than a redesign <seb128> and better to not make those api public if not required <jpetersen> seb128, yes ok i will do <seb128> thanks <seb128> we also need to make sure to not break the screensaver lock screen <vish> tedg: would Bug #391414 be addressed for Lucid? seems to be an a11y problem <ubot4> Launchpad bug 391414 in hundredpapercuts "Unable to shutdown system from GNOME using keyboard (affects: 1)" [Undecided,New] https://launchpad.net/bugs/391414 * vish thinking of assigning milestone for Lucid <tedg> vish: Yes, please do. <vish> tedg: shall i assign it to you? <tedg> vish: No, all bugs should always be assigned to kenvandine, it makes him feel loved ;) <tedg> vish: Yeah, to me :) <vish> hehe ;) * vish first searches for dupes <dpm> hi jpetersen, I've been talking to jcastro about a translation issue from the Rhythmbox indicator and he told me you'd be the person to ask. <dpm> Here's the question: <jpetersen> hi dpm <dpm> hi :) <dpm> The "Show Rhythmbox" message on http://imagebin.ca/view/2Vubpv2T.html appears untranslated, and I'd like to find out why it's not translatable. The string does not seem to come from Rhythmbox itself. Any idea where it comes from? <jpetersen> dpm, it is from plugins/status-icon/rb-status-icon-plugin.c <dpm> ah, thanks jpetersen, let me have a look... <jpetersen> dpm, hm the app-indicator patch changed it from "Show Music Player" to "Show Rhythmbox", that was in the original patch <jpetersen> dpm, I am not sure why it was changed <dpm> I'm just looking at why the Show Rhythmbox message does not appear in the Ubuntu translation template, perhaps it was not marked as translatable in the patch <jpetersen> dpm, it is marked translatable <dpm> weird, the only similar message is "_Show Rhythmbox" in the Ubuntu template -> https://translations.launchpad.net/ubuntu/lucid/+source/rhythmbox/+pots/rhythmbox/ca/+translate?batch=10&show=all&search=show+rhythmbox <jpetersen> dpm, yes that is the right one <dpm> it's not, the one shown does not have the accelerator -> "Show Rhythmbox" <> "_Show Rhythmbox" <jpetersen> dpm, it seems there seems to be a problem with accelerators in the indicator applet <jpetersen> dpm, but it is that string <dpm> jpetersen, (sorry, I was on the phone). Ah, ok. Do you know if the problem with accelerators a known bug? If so, I'll subscribe to it, otherwise I'll file a new one, I just want to make sure that that string's translations are loaded <jpetersen> dpm, I have not found any bug <dpm> jpetersen, no worries, if it's actually that string, and if it's discarding the accelerator, I'll file a new one. Which source package would be the best to file it against? <jpetersen> indicator-application <dpm> thanks a lot for your help jpetersen! <jpetersen> dpm, your wlecome <Nafai> Hi guys <Nafai> Back from my appointments <jcastro> Nafai: I believe pitti had some questions outstanding on the vino work <Nafai> Ok <jcastro> Nafai: how's brasero coming along? <Nafai> No comments yet from upstream <Nafai> Fine, got one last issue if I don't figure it out soon I'll reach out for some help <jcastro> Nafai: oh right, you needed a GTK guru right? <Nafai> in general, yes, but for the specific problem now for brasero it is more of figuring out the right callback <jcastro> perhaps jpetersen? <jcastro> we need a box with glass and jpetersend in it ... "Break in case of App Indicator Emergency" <Nafai> Heh <Nafai> Give me a few minutes and I'll see if I need help this time * jcastro nods <jpetersen> jcastro, Nafai what is the problem? <Nafai> jpetersen: not an immediate problem at the moment, but are you going to be around for a while? <jpetersen> Nafai, yes I will have dinner soon, but I will continue to work for a bit after that <Nafai> Ok, I'll try to ping you quickly if I need help today <Nafai> thanks for being available <jpetersen> Nafai, ok :) <jpetersen> your welcome <jcastro> qense: hey, did you know we had a karmic app-indicator ppa already? <qense> jcastro: no :P <qense> Where? <jcastro> it's listed on the wiki page <qense> lol <jcastro> heh, it's been there since like December. :D <jcastro> for upstreams who want to play but don't want to run Lucid <C10uD> tedg, (sorry for the pinging) about bug 527061 , i posted a new diff. however, today i managed to correctly build the whole stuff, and seems like the 001 diff works correctly while the new one (002) doesn't. unfortunately there's little (read: no) documentation on bindings creations so i'm walking in the dark (i don't know how duplicate a constructor). any chance some expert can take a look at this? anyway, the 001 seems fine to me, if you wanna test it <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 <tedg> C10uD: I'm not sure how to do that in Python either. kenvandine, do you know how to overload a constructor? <C10uD> well, shouldn't be safe to use *_new_from_model? with plain *_new that path is set to Null, so there's little difference i think <Nafai> You don't overload the constructor in Python <Nafai> What I would do is add an optional parameter to __init__ <C10uD> Nafai, but the defs file allows to specify optional parameters for the method from what i've read, and that's what i used <C10uD> it's just i'm using _new_from_model instead of plain _new when creating a new appindicator object, and i think there should be no difference (even if i didn't read the source, i admit) * Nafai nods <C10uD> using _new sets that parameter to Null already <C10uD> sorry if i'm bothering too much, but i really need that upstreamed in order to hax icons in the indicator :p <tedg> C10uD: I don't think it's an issue, just no one is quite sure how it should work. <C10uD> that sounds very reassuring <C10uD> heh <C10uD> anyway, here's my reference http://live.gnome.org/PyGTK/WhatsNew28#Hand-written_constructors_need_to_be_updated <C10uD> notice that appindicator seems using some going-for-deprecation syntax for bindings creation, but that's another story <C10uD> anyway, if there's something i can do to speed up the process let me know, i fear about python bindings be not ready for lucid.. <Nafai> bbiab, lunch <jcastro> qense: that was awesome! * qense blushes <jpetersen_> I am going to leave for the day <jpetersen_> bye bye <Nafai> jcastro: brasero patch attached and ready for review! <Nafai> jcastro: should I go back and separate the vino patch into two patches as suggested by pitti, or work on gnome-bluetooth first? <jcastro> Nafai: pitti's work first <Nafai> okay, figured as much <jcastro> good job on brasero btw! <Nafai> thanks <Nafai> Is the opportunistic developer week going well? I've forgotten to pay attention today :( <jcastro> yeah, qense ran an app indicator session <Nafai> awesome <Nafai> He rocks <seg|ars> mpt: hey, is that bold/italic thing an official twitter feature? I haven't seen that before <seg|ars> mpt: it appears to be using an egregiously eccentric unicode hack <mpt> seg|ars, no, it's a practical joke <seg|ars> haha <mpt> Feel free to play along or dismiss it at your choice <mpt> seg|ars, I'm sure you could think of some earnest pledge to support all #twitterpremium features in Gwibber 3.0 <seg|ars> mpt: http://img268.imageshack.us/img268/6862/gwibber3zomg.png ;-) <mpt> seg|ars, beautiful <mpt> seg|ars, misspelled the hashtag :-( <seg|ars> mpt: fixed. Thankfully, one of the new premium features is support for editing existing messages! <mpt> Yeah, isn't it cool? <seg|ars> indeed #ayatana 2010-03-02 <Nafai> Question regarding i10n, as far as the translation mechanism is concerned, N_("Close") is different from GTK_STOCK_CLOSE, right? <Nafai> jcastro: So today, I'm following up with pitti's comments on my brasero changes and then gnome-bluetooth, etc <Nafai> jpetersen: You around? <jpetersen> Nafai, yes <jcastro> rock and roll! <jpetersen> Hello :) <jcastro> Nafai: did you split up vino btw? <Nafai> Yes <Nafai> (did I forget to mention that in my status report?) <jcastro> dunno that was yesterday, sorry I forgot <Nafai> heh :) <Nafai> you've slept since then, I hope <jcastro> heh, yeah <Nafai> I have a couple problems. In order to remove the icons from the app indicator menu for brasero, I changed the GtkActionEntry to not use GTK_STOCK_CANCEL for the id but to just use N_("Cancel") for the string <Nafai> (The patch is here: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/497853/comments/6) <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] <jcastro> mpt: when you get a chance please update, log out and back in and check gnome-power-manager's label things in the menu and let us know what you think. <Nafai> But then that messes up the translations <Nafai> But I'm not sure how to remove the icons if I use GTK_STOCK_CANCEL for the id in the GtkActionEntry <Nafai> jpetersen: Any ideas? <Nafai> I need to go run some errands for a while (yay more doctor stuff), but I'll check back <jpetersen> Nafai, hm I do not have a really good idea for that <Nafai> ok :( <jpetersen> I will be offline for an hour will be back later * Nafai is back * hyperair wonders if anyone else frequently killall's notify-osd <qense> tedg: Have you had the time to look at my mail lately? <qense> hyperair: never needed, actually <qense> memory leaks? <tedg> qense: Hmm... no, I'm not sure which e-mail you're talking about. <hyperair> qense: yes. =( <tedg> qense: Did I miss one? <qense> tedg: I think so. <hyperair> qense: my uptime is only 6h this round. <qense> tedg: I sent it to the first e-mail address on the list on your Launchpad profile. <qense> Maybe it got spammed. <qense> Shall I sent it again? <tedg> qense: Found it. Sorry... looking now. <qense> tedg: ok <qense> hyperair: Did you report a bug for that behaviour? <hyperair> qense: i think i did. <hyperair> qense: a long long time ago.... <hyperair> (in a galaxy far far away) <qense> It may still get fixed, I just got an update for GNOME Pilot that fixed a bug with a number in the 100,000. <hyperair> qense: i think it's related to the images passed to notify-osd. <hyperair> qense: the higher res pictures you pass to it, the faster it leaks. <qense> weird, what images are you receiving then? <hyperair> qense: and i've got a lot of high-res album art <qense> that could be the cause of it <qense> valgrind! <hyperair> qense: have you ever stuffed a gobject/glib using program into valgrind before? <hyperair> qense: you get a million and one errors and warnings and you can't even tell what's wrong and what's right anymore <qense> hyperair: Frankly, I've never used valgrind before. <tedg> qense: Yeah, the issue is that you're trying to send the enums over dbus -- which really doesn't work. <qense> hyperair: Report them alL! <qense> tedg: not even a tiny bit? <qense> :( <tedg> qense: The values need to be sent over dbus as strings, and then translated back. <tedg> qense: Yeah, one of the reason is that it doesn't match the KDE spec. <tedg> qense: Which is all strings. <hyperair> qense: nobody in the right mind is going to stare at the million and one false positives there are <tedg> qense: We could of course send ints if we weren't matching that spec. <tedg> qense: But we can't send GType enums as the dbus bindings aren't smart enough to turn those into ints. <qense> that's a shame <tedg> qense: So for the parts that touch dbus, they need to be int/strings. <qense> tedg: tedg: The thing is that everywhere in the AppIndicator class they should be of the correct type, otherwise the bindings for C# don't work properly. <tedg> qense: Yeah, we're getting better GLib Dbus bindings in the next rev of Glib -- but that's another 6 months off (at least) <tedg> qense: So can we hide the "dbus parts" of the class from C#? <tedg> qense: Like make the bindings not have some of the signals in them. <qense> tedg: the issues with the bindings are mostly in the set_ and get_property methods <tedg> qense: Can those be wrapped in some clever way? <qense> tedg: Do you really need the set_ and get_ property methods to save and return strings? <qense> Otherwise we would let get_property() translate the string to the correct type and return that. <tedg> qense: Yes, those are the functions that dbus calls to get the properties. <qense> Then we have a problem <qense> the C# bindings call those as well <tedg> Can the C# bindings translate the enum values into strings? It seems some sort of polymorphism should help. <tedg> So you could still set the value, it'd just translate using the g_* values when it's needed. <qense> tedg: That is only possible to do if most methods of the bindings would be written manually and added to the .custom file, which would mean you'd have to maintain two libraries instead of one. If we can get everything to be generated using the .metadata file, which is what I'm working on, it's just a matter of running the Makefile and everything gets generated just fine. <qense> Moreover, overriding the Fallback and Unfallback methods requires the inheritance of the whole class. <qense> If you want to do that you either need to specify the arguments of the constructor in the .metadata file, which is when GAPI expects them to be saved in the type you're giving. <qense> Otherwise you need to manually write a constructor. <qense> and maintain it <tedg> Hmm, so then in Mono could we ditch the idea of the enums entirely, and let people just use strings through some sort of const. <tedg> You wouldn't get the benefit of the enum, but we'd make it easier to maintain. <qense> tedg: That way we'd only have to implement two custom type definitions. <qense> Which is doable. <Nafai> Hi jpetersen <jpetersen> Hi <Nafai> So I need some advice on this: https://bugs.launchpad.net/ubuntu/lucid/+source/brasero/+bug/497853/comments/8 <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] <Nafai> jcastro, mpt ^ <Nafai> Here's the deal. With the GtkStatusIcon, when you click it once burning is done, it closes. So, do replicate behavior, I have changed the Cancel menu item to Close in the App Indicator <Nafai> The translation issue is that I have use N_("Close") instead of GTK_STOCK_CLOSE so the icon wouldn't show <Nafai> And I wonder what the help string should be <jpetersen> Maybe it could help to only display images in app indicator when the "always-show-image" property is TRUE for the GtkImageMenuItem <jpetersen> but that probably than does not display some images which should be shown else * Nafai nods <Nafai> tedg suggested we handle this in each app right now <Nafai> And so I'm struggling to figure that out <jpetersen> Yes <Nafai> For example, my next task is to hide the menu items in gnome-bluetooth <Nafai> I really don't want to mess with the glade file and would rather do it at runtime (minimize changes to go upstream) <Nafai> There are menu items with the icon-name property set <Nafai> Would I just turn it off by setting the icon-name property to "" or NULL? <jpetersen> Yes that should help usually <Nafai> Ok, that's what I'll try <mpt> Nafai, in a user testing session right now, I'll look at it in a moment <Nafai> mpt: thanks <Nafai> jpetersen: Darn, one of the problems with gnome-bluetooth is that it uses stock-id in some cases :( <jpetersen> Nafai, yes stock-id is annoying in that case <Nafai> because that forces an icon because it becomes a GtkImageMenuItem, right? <jpetersen> one could try gtk_image_menu_item_set_image (item, NULL) <Nafai> I'll see what that does <seb128> jcastro, jpetersen: gnome-settings-daemon uploaded to lucid now <jcastro> \o/ * mpt finally gets some time to look at Nafai's bug <Nafai> thanks <mpt> ah, right <mpt> This is one of the applications that shouldn't be in the panel at all <Nafai> oh <mpt> But we have money to burn, so... :-) <Nafai> so much for what I've done :) <mpt> let's see <mpt> Completely not your fault at all <mpt> hm <mpt> Looking at the patch, you have a "Cancel" item and then a "Close" item? <Nafai> Yes <Nafai> cancel for when the burn is in place, and then when it is done, close <mpt> What is the difference? <Nafai> (only one is shown at a time) <mpt> oh <Nafai> this mirrors the dialog <mpt> Is that what the notification area item did too? <Nafai> it didn't change the item <Nafai> but when you left clicked, it closed the dialog and went away <Nafai> it had a right-click menu <mpt> What did the right-click menu have in it? <Nafai> Show and cancel <jcastro> mpt: we could use feedback on the power manager changes that landed today too <mpt> Nafai, and what happened to the notification area menu when the burn was done? <Nafai> no changes <mpt> Nafai, so it still had a sensitive "Cancel" item that did nothing? <Nafai> I think so, let me verify <mpt> don't waste a disc on my account :-) <mpt> Nafai, how about, instead of making the whole thing disappear when you choose "Close", make the whole thing disappear (but leave behind the window) as soon as the job is complete? <Nafai> I can burn to iso, so no biggie <Nafai> Yes, no menu changes <mpt> so we're effectively fixing a bug in Brasero no matter what we do <Nafai> yeah <mpt> Nafai, if you remove the whole menu when the burn finishes you don't need to add a new item. <Nafai> correct <Nafai> mpt: automatically remove the app indicator, and then make sure the dialog is visible? <mpt> Nafai, no need to make sure it's visible, there's no hurry <mpt> maybe request attention on it <Nafai> ok <Nafai> well, you can show and hide the dialog from the menu, which is what I mean by make visible <Nafai> not necessarily bring to foreground <mpt> oh, right <mpt> yes <mpt> jcastro, I've installed them, but haven't had time to restart yet sorry <jcastro> mpt: no worries, I was mulling if the same idea applied to the rhythmbox one would be a good idea <Nafai> thanks for the advice mpt <mpt> jcastro, Rhythmbox would be another example of one that would be counterproductive to port for Lucid <mpt> you're welcome Nafai <mpt> jcastro, oh, but that's mostly done isn't it <mpt> That's why there's people complaining about the tooltip <mpt> Sorry, forgot that, it seems like ages ago :-) <jcastro> mpt: at this rate you're basically saying that porting nothing to app indicators is a good idea <Nafai> :( <mpt> jcastro: gnome-control-center, vino, ekiga, gnome-settings-daemon, gnome-gmail-notifier, xchat all make sense to port <hyperair> oh hey so mpt agrees with me <hyperair> re tooltips <hyperair> gnome-control-center has an application indicator? what does it use it for? <mpt> jcastro, a second class should be adjusted to not use the notification area at all <mpt> jcastro, and a third class (e.g. Tomboy) should be ported eventually, but appindicator doesn't have the special stuff they need yet (e.g. grid layout) <mpt> hyperair, Rhythmbox is in the third class -- not necessarily a tooltip, perhaps a better mechanism ;-) <hyperair> mpt: what do you mean third class? <hyperair> mpt: and i'm speaking from banshee's point of view, which should essentially be the same as rhythmbox in this area. <mpt> hyperair, ^^^ <jcastro> hyperair: gnome-cc uses it for the typing break thing <hyperair> ah typing break. <hyperair> i've never used that before. perhaps i should give it a run.. * hyperair flexes left wrist <hyperair> mpt: third class meaning a better mechanism than a tooltip? <mpt> hyperair, maybe <hyperair> mpt: er wait, what are these classes referring to? <mpt> hyperair, categories of applications that have been using the notification area. <hyperair> ah <mpt> we have two goals <mpt> (1) reduce the number of them <mpt> (2) make the remainder behave consistently <mpt> We get #2 by making them a single set of menus <mpt> We're not doing so well with #1 at the moment. <hyperair> mpt: what i don't really agree with is the complete removal of tooltips. i understand that it would be desirable to make them all follow a consistent interface, but menus have text buttons. these are icons without text. <hyperair> mpt: in other words, these are more like toolbar icons that have dropdown menus when clicked. <mpt> I think it would be useful to brainstorm different ways of showing the track info <mpt> It's kind of crazy that music players have been showing it in three different ways <hyperair> three? <mpt> 1 in the player window itself, 2 in notification bubbles, 3 as a tooltip in the notification area <hyperair> i know of the tooltip, what are the other two? <hyperair> ah. <hyperair> well i think 2 and 3 have their own reasons. <hyperair> 1 as well <hyperair> it wouldn't make sense to not show the track in the player window. <hyperair> notification bubbles are transient and show a change of track <hyperair> and tooltips are so you don't have to open the big player window to check the currently playing track, after the notification bubbles have expired. <mpt> Any two of them you could merge, with a bit of work <hyperair> i don't see how #1 could be merged with any of the other two. <mpt> (1) and (2) could be merged by making a pseudo-notification-bubble that appeared in exactly the same place, and with exactly the same layout, as the information in the window wherever the window happens to be <hyperair> #2 and #3 could be merged, by forgoing notify-osd style popups and showing that tooltip for a brief period when changing. <mpt> exactly <hyperair> i don't see how #1 and #2's merge can be even considered a solution. <hyperair> exactly in the same place <hyperair> considering player windows can move all over the place, your notification bubble is going to also move all over the place <hyperair> and it's going to obstruct whatever the user is doing <mpt> notification bubbles already obstruct some people wherever they are :-) <hyperair> notify-osd minimizes that. <mpt> but yeah, it would be more likely nearer the center of the screen <mpt> This is all just brainstorming, not saying any of these are brilliant ideas <hyperair> heh <hyperair> right <hyperair> mpt: there was also the issue about mouse feedback on the notification area icon/app indicator, although that is much less of an issue than the tooltip. <Nafai> what do you mean by mouse feedback? <mpt> ditto <hyperair> Nafai: middle click to play/pause. <hyperair> scroll to change track. <Nafai> oh, I see <hyperair> mouseover for too-er wait, that's tooltips. <Nafai> I never realized that the old rhythmbox thingy allowed that :) <hyperair> i don't speak for rhythmbox. i speak for banshee. <hyperair> tbh i can't be assed about what happens to rhythmbox really =p <Nafai> oh, sorry <hyperair> i'm not sure whether rhythmbox allowed that though <hyperair> it might have <hyperair> i know amarok did during the kde3 days. <hyperair> i'm not sure if it still does. <hyperair> even exaile allows it somewhat <hyperair> i think exaile does volume though <Nafai> jpetersen: Around still? (I realize it is late there :)) <Nafai> Or anyone else that might know GtkBuilder or gtk menus in general <Nafai> I'm having a hard time getting a reference to the menu items I want so I can turn off their icon and I could use some guidance <jpetersen> Nafai, hi <Nafai> Hi jpetersen <jpetersen> Nafai, which application is it? <Nafai> gnome-bluetooh <Nafai> gnome-bluetooth <Nafai> So it uses this glade file: http://git.gnome.org/browse/gnome-bluetooth/tree/applet/popup-menu.ui?id=GNOMEBT_V_2_29_91 <Nafai> er, gtkbuilder file <Nafai> and then builds the menu: http://git.gnome.org/browse/gnome-bluetooth/tree/applet/main.c?id=GNOMEBT_V_2_29_91#n361 <Nafai> if I try getting at the menu item using gtk_builder_get_object (xml, "preferences"), it returns the GtkAction, not the GtkMenuItem <Nafai> And I don't know how to get at the menu item <jpetersen> Nafai, ah yes I think you need to get the ui-manager with gtk_builder_get_object (xml, "bluetooth-applet-ui-manager"); <Nafai> Ah, I didn't notice the ui manager there <jpetersen> and than the widget with gtk_ui_manager_get_widget <Nafai> right <Nafai> I think I can do that. Thanks :) <jpetersen> the path in gtk_ui_manager_get_widget is something like "/bluetooth-applet-popup/preferences" than :) <jpetersen> your welcome :) <jpetersen> I will leave now <jpetersen> good night :) <ryanprior> Is anybody working to patch Gwibber to handle Google Buzz before Lucid? <jcastro> the <jcastro> APIs aren't public yet afaik <sanderqd> http://code.google.com/apis/buzz/ seems you can only retrieve updates, and post them from another connected site #ayatana 2010-03-03 <seb128> jpetersen, hi <jpetersen> seb128, hi <seb128> jpetersen, so we will probably roll back the keyboard switcher things for lucid, sorry about that, please still fix the by one offset <jpetersen> seb128, yes ok i will do <seb128> we will need app-indicator to support labels to fix that one properly as you indicated <jpetersen> yes <seb128> seems users rely on the layout to be indicated <jcastro> tedg: when do we plan to support labels? <jcastro> seb128: ok, so that basically means nothing in g-s-d will be ported? <tedg> jcastro: I don't know if we will or not. I don't think that's decided. <tedg> jcastro: I think that's probably the only way to do things like the keyboard selector though. <jcastro> ok so basically we're reverting all of g-s-d <tedg> jcastro: No, just the keyboard selector. <tedg> jcastro: Why all? <jcastro> so what's left in g-s-d that is ported? <tedg> jcastro: I don't remember, but I thought there were four in g-s-d. <jpetersen> currently there is display, universal access and keyboard <jcastro> display had funky UI so we didn't do that <seb128> jcastro, the a11y keyboard icon and xrandr are still ok <seb128> we replaced the funky colored ui by a label <seb128> no complain about that so far <jcastro> wait, which xrandr thing are we talking about <seb128> jcastro, gnome-display-properties <seb128> check the box at the bottom there <jcastro> ok that's showing up in my old area still <seb128> did you restart your session since the g-s-d update? * jcastro checks his laptop <jcastro> seb128: wow I totally missed that! * jcastro whistles <jpetersen> I left it in the patch for now, because I was not sure what was the final decision about it <jpetersen> if we really need the colored boxes we would need to revert it to GtkStatusIcon also <jpetersen> I am just offline for half an hour will be back than <jcastro> seb128: ok should I update #531173 with the outcome then? <seb128> jcastro, please do <jpetersen> I am back <jpetersen> ok, I will revert the keyboard indicator for now <jcastro> woo! <jcastro> jpetersen: did you get my mail about rhythmbox? <jpetersen> jcastro, yes I am just testing the change I did <jpetersen> to implement it <jcastro> \o/ <Nafai> Good morning <jcastro> Nafai: good morning! <Nafai> Good morning! <Nafai> How's it going? <jcastro> good <jcastro> https://bugs.edge.launchpad.net/ubuntu/lucid/+source/brasero/+bug/497853 <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] <jcastro> can you look at this today? <Nafai> Yes, I just need to finish up with what mpt and I talked about <jcastro> awesome <jcastro> and looks like you made the changes to vino that pitti wanted? <Nafai> yes <Nafai> and I'm almost done with a solution for gnome-bluetooth <jcastro> \m/ <jpetersen> jcastro, the rhythmbox labels work now, I needed to work around a gtk+ bug <jpetersen> jcastro, I will upload the patch to the upstream bug after dinner * jcastro nods <jcastro> jpetersen: thanks for being flexible! <jcastro> smithj: can you look at https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/497877 asap please? <ubot4> Launchpad bug 497877 in hplip (Ubuntu) (and 1 other project) "Support Application Indicators (affects: 1)" [Wishlist,Incomplete] <Nafai> jcastro: Should my patch for bug #528527 be a new patch separate from the previous app-indicator patch? <ubot4> Launchpad bug 528527 in gnome-bluetooth (Ubuntu) "Extraneous icons throw off alignment in indicator menu (affects: 1)" [Undecided,In progress] https://launchpad.net/bugs/528527 <jcastro> seb128: ^^ <jcastro> Nafai: whatever is easier for seb/pitti * Nafai nods <jcastro> I am looking forward to this one, that menu looks pretty bad with the icons <Nafai> Yeah <mpt_> DanRabbit, hi, what are you working on at the moment? <DanRabbit> mpt_: odds and ends :) <DanRabbit> mpt_: what can I do for you? <mpt_> DanRabbit, I guess ivanka has told you about the various icons for Ubuntu Software Center <DanRabbit> mpt_: indirectly, I'm supposed to be working on two specific icons <mpt_> DanRabbit, which ones? <jcastro> seb128: ok his changes to rhythmbox for those labels is attached to the bug fyi <seb128> jcastro, I noticed thanks <Nafai> seb128: Should my patch for bug #528527 be a new patch separate from the previous app-indicator patch? <ubot4> Launchpad bug 528527 in gnome-bluetooth (Ubuntu) "Extraneous icons throw off alignment in indicator menu (affects: 1)" [Undecided,In progress] https://launchpad.net/bugs/528527 <seb128> Nafai, let me look <Nafai> thanks <seb128> do we think that the change would make sense for upstream too? <seb128> and does that require changing upstream code or indicator one? <Nafai> it's an addition to the patch we've already made for app-indicator code (within #ifdef blocks), I don't think it makes sense for upstream unless they accept app indicators too <seb128> ok so please update the current distro change <seb128> don't create a new patch for that <Nafai> ok <Nafai> so you will just update the current patch in debian/patches? <Nafai> I'll attach a patch to do so then <seb128> Nafai, yes <Nafai> thanks <Nafai> So is this awesome new theme jono blogged about available yet? <jcastro> should be landing soonish <Nafai> nice <Nafai> looks awesome <jcastro> yeah it really rocks out the app indicators doesn't it <Nafai> I'm about to land two new/updated patches (gnome-bluetooth and brasero) <jcastro> \o/ <mpt_> whoo <jcastro> mpt_: this should fix the crappy looking icons in gnome-bt <mpt_> Oh, and g-p-m shows me the time remaining now, hurrah <jcastro> mpt_: we've got that kind of thing for RB too <Nafai> Is that wallpaper the final wall paper? I think my wife will appreciate it too. She actually just changed the theme on her netbook to make it "pretty" <mpt_> That is the stretch limo of menu items, though, isn't it <mpt_> "Laptop battery 2 hours 25 minutes remaining (99.4%)" <jcastro> mpt_: in rb it will elipsize after 40 characters <mpt_> nice <jcastro> mpt_: any ideas on how to make it suck less in g-p-m would be appreciated! <mpt_> jcastro, the PowerStatusMenu spec has "H:MM left" rather than "H hours MM minutes remaining" <jcastro> mpt_: can you file a bug and I'll triage it to the right place? <jcastro> mpt_: sorry you caught me in the middle of something. :D <mpt_> Don't look, everyone, jcastro is going through some painful branding <mpt_> j/k <Nafai> heh <mpt_> jcastro, bug 531620 <jcastro> mpt_: triaged <lamalex> so what happened to the bottom panel in the new desktop mockups <lamalex> no window list? <Nafai> ok, my patches are ready and I'll upload them as soon as the launchpad maintenance window is over :) #ayatana 2010-03-04 <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 <Tiibiidii> hortcut) action put in a less easily accessible position, and meanwhile promoting the other actions in the corner... <Tiibiidii> right now i tweaked my gconf settings to replicate the future lucid theme <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 <Tiibiidii> in the meanwhile, can someone point me to the reasoning that sits behind this change? <Nafai> jcastro: around? <Nafai> (I know it's late for you) <jcastro> Nafai: yeah <jcastro> what's up? <Nafai> Should I assign bug #497853 back to pitti or to canonical-desktop-team? <ubot4> Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] https://launchpad.net/bugs/497853 <jcastro> pitti <jcastro> i'll ping him tomorrow early and see if that's what he wants <Nafai> ok <lamalex> i posted a patch for https://bugs.edge.launchpad.net/hundredpapercuts/+bug/460286 <ubot4> Launchpad bug 460286 in empathy (Ubuntu) (and 2 other projects) "enable notifications when chat is not focused (affects: 3)" [Wishlist,Triaged] <vish> kenvandine: ^^ <jcastro> seb128: woo, brasero is in! <seb128> jcastro, only vino left? <jcastro> and hplip <jcastro> but hplip has been through the pitti gauntlet already, needs an update <jcastro> smithj: ping <seb128> ok <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 <seb128> jcastro, good <Nafai> Good morning <Nafai> I'm going to go ahead and pass brasero and gnome-bluetooth patches upstream this morning <jcastro> Nafai: anything left to do on vino on your side? <Nafai> nope, I've already passed the updated patches upstream and attached to the launchpad bug <Nafai> brb <Nafai> back <seb128> hey Nafai <seb128> I commented on your gnome-bluetooth change <seb128> I think we didn't understand each other yesterday <Nafai> Oh * Nafai looks <seb128> I suggested changing the menu directly <seb128> ie the .ui <seb128> not doing weird code hacks <Nafai> well, for the items that us stock-id, if I change it to not use stock-id, we lose translations <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 <seb128> well that's why I asked you yesterday <seb128> is there any reason why they would want icons and we don't <seb128> we use the same menu is both cases <seb128> if icons don't look nice they should be cleaned in both cases <seb128> no? <Nafai> I'm trying to find a screenshot to see how they looked in the old one <Nafai> actually, in Ubuntu at least, the status icon respects the no-icon menu setting <Nafai> so they aren't shown anyway <seb128> why doesn't the indicator do that? <seb128> isn"t that an indicator bug? <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 <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 <jcastro> I don't remember <jcastro> Nafai: it's like UI freeze today so it's like our last chance to get it right <Nafai> what's your take on this jcastro? <Nafai> For the record, I don't disagree with seb128, I just want to do the right thing <seb128> jcastro, well making the applet respect the show icon flag would be a bug fix not an ui change <seb128> even if side effect is to fix an ui which was buggy <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. <seb128> let's wait on ted <jcastro> Nafai: when in doubt I always do what seb128 wants and everything works out. :D <jcastro> at least brasero is done, what a pain in the neck <Nafai> Our conversation from the other day: http://paste.ubuntu.com/388287/ <seb128> speaking of who <seb128> tedg, hy <seb128> hey <tedg> Good morning. <seb128> tedg, so we were talking about the bluetooth indicator <seb128> and stock icons <seb128> is indicator applet not respecting the show icon option a known bug? <seb128> will it be fixed for lucid? <tedg> It's known, but I forgot about it :) <tedg> It shouldn't be too hard to fix. <jcastro> tedg: what's your schedule like today? It would be nice to get this fixed <jcastro> ugh, it's thursday <tedg> Heh, jcastro you're getting the rhythm ;) <seb128> Nafai, ^ <seb128> jpetersen, hi <jpetersen> seb128, hi <seb128> jpetersen, thanks for the rhythmbox update <seb128> jpetersen, it doesn't escape markers though <seb128> the <i></i> are displayed <jpetersen> seb128, hm ok <seb128> rather than having those words in italic <seb128> did it works for you? <jpetersen> seb128, it was not shown here <jpetersen> seb128, I will just test it again <seb128> jpetersen, thanks <Nafai> Ok, brasero passed upstream <Nafai> brb <hyperair> is application indicator supposed to use that much padding? * hyperair really dislikes having that much padding for anything. <jpetersen> seb128, ah ok I can reproduce that problem, I will fix it <Nafai> hyperair: You mean between icons? <seb128> jpetersen, thanks! <seb128> Nafai, so if ted fixes the show icon issue, is there anything left to change in bluetooth? <Nafai> seb128: Nope. So that should take care of #528527, nothing needs to be done with the package, right? <hyperair> Nafai: yes, between the icons. <seb128> Nafai, ok, what I think too, good ;-) <Nafai> so I'll go ahead and pass the existing patch (the one already packaged) upstream <seb128> Nafai, thanks <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 <Nafai> I should probably do that and double check the other things were done <seb128> ok <Nafai> I've got a call here in a few minutes, but I can quickly make those changes after <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. <tedg> hyperair: I think something might be getting padded twice. <hyperair> tedg: i see. what's the padding for? <hyperair> tedg: isn't the notification area cluttered enough without padding stretching it even wider? <tedg> hyperair: Just to make it easier to hit the items. And to make them look nice. (probably more the second) <hyperair> heh <hyperair> alright * hyperair will need to undergo panel appletsectomy after upgrading to lucid <seb128> fedora did extra padding change previous cycle in their notification area too <hyperair> hmm, did they? <seb128> yes <hyperair> but they don't have appind do they? <hyperair> so this padding is for the notification area icon alone? <seb128> no <seb128> yes <hyperair> i mean notification area <seb128> http://blogs.fedoraproject.org/wp/mclasen/2009/10/26/5-little-things/ <seb128> the second item on the list there <jpetersen> seb128, I updated the rhythmbox patch to fix the markup issues <seb128> jpetersen, oh, nice, looking <hyperair> seb128: interesting. <jpetersen> I will be back soon <qense> Is bug #528088 valid for all AppIndicators? <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 <seb128> qense, indicator fallback to a notification area icon <seb128> that bug is weird <seb128> I usually have the opposite issue <seb128> I've to make sure the service is not running to have the fallback working <seb128> ie removing the indicator applet with the service still running breaks <qense> seb128: I've stumbled about your issue a few time as well. <seb128> but once you stop the service it works <qense> that's true <qense> the service keeps running <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. <qense> Both the service and the applet could use it. <qense> and probably many other applications as well. <seb128> qense, bug #532044 is a duplicate <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 <seb128> please close it <qense> seb128: will do, thanks for mentioning <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? <qense> I've dumped bug #527282 in gtk+2.0, but is that the right place for it? <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 <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. <qense> Before AppInd you could raise the hidden windows from the tray. <Nafai> Okay, I just finished #532104 <Nafai> bug #532104 <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 <Nafai> Addresses feedback seb128 gave me before that I missed <jcastro> Nafai: woo! <Nafai> If this is good, I'll pass it upstream <jcastro> Nafai: tomorrow I was thinking of sending the brasero and vino guys a mail <jcastro> if we could have a call I'd like to get some things straight <Nafai> K, vino has been sitting there for like a week or something <Nafai> sure thing <jcastro> explain why it's so invasive, etc. <jcastro> yeah <Nafai> pitti and I successfully used Empathy/gtalk earlier today <Nafai> worked well <jcastro> yeah it's getting much better <jcastro> last cycle I couldn't use it at all but it's pretty good now <jcastro> all it really needs is voice cancellation <Nafai> yeah <Nafai> I'm going to go grab lunch <Nafai> Then I'll need to figure out what's next :) <Nafai> back <Nafai> jcastro: what would you suggest I work on next? <jcastro> well, no outstanding bugs at the moment. <jcastro> Maybe qense needs help with the banshee work? <jcastro> Nafai: we're at UI freeze so it doesn't really make sense to port new apps <Nafai> right <Nafai> qense: Around? <jcastro> seb128: anything you guys need help with? <qense> jcastro, Nafai: I'm around <Nafai> Need any help with Banshee? <seb128> jcastro, landing the new artwork in lucid? ;-) <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. <qense> seb128: Plymouth should be there already, I'm anxiously waiting for the rest! <seb128> jcastro, out of that nothing I can think about today no <jcastro> ok <seb128> qense, yeah I know <seb128> qense, wallpaper too <qense> yes, forgot that one <seb128> qense, I just uploaded the gnome-panel icon theme <jcastro> tedg: how are your indicator-application bugs? perhaps Nafai can lend a hand when he's not fixing the apps themselves? <Nafai> Yeah, I don't mind diving in <qense> Although I have to say that I am closing in on the Mono binding problems with AppInd. <Nafai> I'm not very experienced with C# or Mono, so I'd probably be less helpful with binding work <qense> Nafai: how much do you know of C# and GAPI? <Nafai> heh. :) <tedg> jcastro: I know of three. The fallback thing in gpm. The fallback on startup. And then the python append
{'channel': 'ayatana', 'month': 3}