| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| Nafai | Question regarding i10n, as far as the translation mechanism is concerned, N_("Close") is different from GTK_STOCK_CLOSE, right? | 14:40 |
|---|---|---|
| Nafai | jcastro: So today, I'm following up with pitti's comments on my brasero changes and then gnome-bluetooth, etc | 14:44 |
| Nafai | jpetersen: You around? | 14:44 |
| jpetersen | Nafai, yes | 14:44 |
| jcastro | rock and roll! | 14:44 |
| jpetersen | Hello :) | 14:44 |
| jcastro | Nafai: did you split up vino btw? | 14:45 |
| Nafai | Yes | 14:45 |
| Nafai | (did I forget to mention that in my status report?) | 14:45 |
| jcastro | dunno that was yesterday, sorry I forgot | 14:45 |
| Nafai | heh :) | 14:45 |
| Nafai | you've slept since then, I hope | 14:46 |
| jcastro | heh, yeah | 14:46 |
| 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 | 14:50 |
| Nafai | (The patch is here: https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/497853/comments/6) | 14:50 |
| ubot4 | Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] | 14:50 |
| 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. | 14:51 |
| Nafai | But then that messes up the translations | 14:51 |
| Nafai | But I'm not sure how to remove the icons if I use GTK_STOCK_CANCEL for the id in the GtkActionEntry | 14:51 |
| Nafai | jpetersen: Any ideas? | 14:51 |
| Nafai | I need to go run some errands for a while (yay more doctor stuff), but I'll check back | 14:59 |
| jpetersen | Nafai, hm I do not have a really good idea for that | 14:59 |
| Nafai | ok :( | 14:59 |
| jpetersen | I will be offline for an hour will be back later | 16:06 |
| * Nafai is back | 16:24 | |
| * hyperair wonders if anyone else frequently killall's notify-osd | 16:33 | |
| qense | tedg: Have you had the time to look at my mail lately? | 16:36 |
| qense | hyperair: never needed, actually | 16:36 |
| qense | memory leaks? | 16:36 |
| tedg | qense: Hmm... no, I'm not sure which e-mail you're talking about. | 16:37 |
| hyperair | qense: yes. =( | 16:37 |
| tedg | qense: Did I miss one? | 16:37 |
| qense | tedg: I think so. | 16:37 |
| hyperair | qense: my uptime is only 6h this round. | 16:37 |
| qense | tedg: I sent it to the first e-mail address on the list on your Launchpad profile. | 16:37 |
| qense | Maybe it got spammed. | 16:37 |
| qense | Shall I sent it again? | 16:37 |
| tedg | qense: Found it. Sorry... looking now. | 16:38 |
| qense | tedg: ok | 16:38 |
| qense | hyperair: Did you report a bug for that behaviour? | 16:39 |
| hyperair | qense: i think i did. | 16:39 |
| hyperair | qense: a long long time ago.... | 16:39 |
| hyperair | (in a galaxy far far away) | 16:40 |
| 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. | 16:40 |
| hyperair | qense: i think it's related to the images passed to notify-osd. | 16:41 |
| hyperair | qense: the higher res pictures you pass to it, the faster it leaks. | 16:42 |
| qense | weird, what images are you receiving then? | 16:42 |
| hyperair | qense: and i've got a lot of high-res album art | 16:42 |
| qense | that could be the cause of it | 16:42 |
| qense | valgrind! | 16:42 |
| hyperair | qense: have you ever stuffed a gobject/glib using program into valgrind before? | 16:43 |
| 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 | 16:43 |
| qense | hyperair: Frankly, I've never used valgrind before. | 16:43 |
| tedg | qense: Yeah, the issue is that you're trying to send the enums over dbus -- which really doesn't work. | 16:43 |
| qense | hyperair: Report them alL! | 16:43 |
| qense | tedg: not even a tiny bit? | 16:43 |
| qense | :( | 16:43 |
| tedg | qense: The values need to be sent over dbus as strings, and then translated back. | 16:43 |
| tedg | qense: Yeah, one of the reason is that it doesn't match the KDE spec. | 16:44 |
| tedg | qense: Which is all strings. | 16:44 |
| hyperair | qense: nobody in the right mind is going to stare at the million and one false positives there are | 16:44 |
| tedg | qense: We could of course send ints if we weren't matching that spec. | 16:44 |
| tedg | qense: But we can't send GType enums as the dbus bindings aren't smart enough to turn those into ints. | 16:44 |
| qense | that's a shame | 16:44 |
| tedg | qense: So for the parts that touch dbus, they need to be int/strings. | 16:44 |
| 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. | 16:45 |
| 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) | 16:45 |
| tedg | qense: So can we hide the "dbus parts" of the class from C#? | 16:45 |
| tedg | qense: Like make the bindings not have some of the signals in them. | 16:46 |
| qense | tedg: the issues with the bindings are mostly in the set_ and get_property methods | 16:46 |
| tedg | qense: Can those be wrapped in some clever way? | 16:48 |
| qense | tedg: Do you really need the set_ and get_ property methods to save and return strings? | 16:48 |
| qense | Otherwise we would let get_property() translate the string to the correct type and return that. | 16:49 |
| tedg | qense: Yes, those are the functions that dbus calls to get the properties. | 16:49 |
| qense | Then we have a problem | 16:49 |
| qense | the C# bindings call those as well | 16:49 |
| tedg | Can the C# bindings translate the enum values into strings? It seems some sort of polymorphism should help. | 16:50 |
| tedg | So you could still set the value, it'd just translate using the g_* values when it's needed. | 16:50 |
| 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. | 16:52 |
| qense | Moreover, overriding the Fallback and Unfallback methods requires the inheritance of the whole class. | 16:53 |
| 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. | 16:53 |
| qense | Otherwise you need to manually write a constructor. | 16:54 |
| qense | and maintain it | 16:54 |
| 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. | 16:56 |
| tedg | You wouldn't get the benefit of the enum, but we'd make it easier to maintain. | 16:57 |
| qense | tedg: That way we'd only have to implement two custom type definitions. | 16:57 |
| qense | Which is doable. | 16:58 |
| Nafai | Hi jpetersen | 17:19 |
| jpetersen | Hi | 17:19 |
| Nafai | So I need some advice on this: https://bugs.launchpad.net/ubuntu/lucid/+source/brasero/+bug/497853/comments/8 | 17:22 |
| ubot4 | Launchpad bug 497853 in brasero (Ubuntu Lucid) (and 2 other projects) "Support application indicators (affects: 1)" [Wishlist,Incomplete] | 17:22 |
| Nafai | jcastro, mpt ^ | 17:22 |
| 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 | 17:24 |
| Nafai | The translation issue is that I have use N_("Close") instead of GTK_STOCK_CLOSE so the icon wouldn't show | 17:25 |
| Nafai | And I wonder what the help string should be | 17:27 |
| jpetersen | Maybe it could help to only display images in app indicator when the "always-show-image" property is TRUE for the GtkImageMenuItem | 17:29 |
| jpetersen | but that probably than does not display some images which should be shown else | 17:29 |
| * Nafai nods | 17:29 | |
| Nafai | tedg suggested we handle this in each app right now | 17:30 |
| Nafai | And so I'm struggling to figure that out | 17:30 |
| jpetersen | Yes | 17:30 |
| Nafai | For example, my next task is to hide the menu items in gnome-bluetooth | 17:30 |
| Nafai | I really don't want to mess with the glade file and would rather do it at runtime (minimize changes to go upstream) | 17:30 |
| Nafai | There are menu items with the icon-name property set | 17:31 |
| Nafai | Would I just turn it off by setting the icon-name property to "" or NULL? | 17:31 |
| jpetersen | Yes that should help usually | 17:31 |
| Nafai | Ok, that's what I'll try | 17:31 |
| mpt | Nafai, in a user testing session right now, I'll look at it in a moment | 17:33 |
| Nafai | mpt: thanks | 17:33 |
| Nafai | jpetersen: Darn, one of the problems with gnome-bluetooth is that it uses stock-id in some cases :( | 17:33 |
| jpetersen | Nafai, yes stock-id is annoying in that case | 17:34 |
| Nafai | because that forces an icon because it becomes a GtkImageMenuItem, right? | 17:34 |
| jpetersen | one could try gtk_image_menu_item_set_image (item, NULL) | 17:36 |
| Nafai | I'll see what that does | 17:37 |
| === MacSlow is now known as MacSlow|capoeira | ||
| === kenvandine is now known as kenvandine[busy] | ||
| === kenvandine[busy] is now known as kenvandine | ||
| seb128 | jcastro, jpetersen: gnome-settings-daemon uploaded to lucid now | 18:37 |
| jcastro | \o/ | 18:41 |
| * mpt finally gets some time to look at Nafai's bug | 19:03 | |
| Nafai | thanks | 19:03 |
| mpt | ah, right | 19:03 |
| mpt | This is one of the applications that shouldn't be in the panel at all | 19:03 |
| Nafai | oh | 19:03 |
| mpt | But we have money to burn, so... :-) | 19:04 |
| Nafai | so much for what I've done :) | 19:04 |
| mpt | let's see | 19:04 |
| mpt | Completely not your fault at all | 19:05 |
| mpt | hm | 19:05 |
| mpt | Looking at the patch, you have a "Cancel" item and then a "Close" item? | 19:05 |
| Nafai | Yes | 19:06 |
| Nafai | cancel for when the burn is in place, and then when it is done, close | 19:06 |
| mpt | What is the difference? | 19:06 |
| Nafai | (only one is shown at a time) | 19:06 |
| mpt | oh | 19:06 |
| Nafai | this mirrors the dialog | 19:06 |
| mpt | Is that what the notification area item did too? | 19:06 |
| Nafai | it didn't change the item | 19:07 |
| Nafai | but when you left clicked, it closed the dialog and went away | 19:07 |
| Nafai | it had a right-click menu | 19:07 |
| mpt | What did the right-click menu have in it? | 19:08 |
| Nafai | Show and cancel | 19:08 |
| jcastro | mpt: we could use feedback on the power manager changes that landed today too | 19:09 |
| mpt | Nafai, and what happened to the notification area menu when the burn was done? | 19:10 |
| Nafai | no changes | 19:11 |
| mpt | Nafai, so it still had a sensitive "Cancel" item that did nothing? | 19:11 |
| Nafai | I think so, let me verify | 19:11 |
| mpt | don't waste a disc on my account :-) | 19:12 |
| 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? | 19:13 |
| Nafai | I can burn to iso, so no biggie | 19:13 |
| Nafai | Yes, no menu changes | 19:13 |
| mpt | so we're effectively fixing a bug in Brasero no matter what we do | 19:14 |
| Nafai | yeah | 19:14 |
| mpt | Nafai, if you remove the whole menu when the burn finishes you don't need to add a new item. | 19:14 |
| Nafai | correct | 19:15 |
| Nafai | mpt: automatically remove the app indicator, and then make sure the dialog is visible? | 19:18 |
| mpt | Nafai, no need to make sure it's visible, there's no hurry | 19:19 |
| mpt | maybe request attention on it | 19:19 |
| Nafai | ok | 19:19 |
| Nafai | well, you can show and hide the dialog from the menu, which is what I mean by make visible | 19:20 |
| Nafai | not necessarily bring to foreground | 19:20 |
| mpt | oh, right | 19:20 |
| mpt | yes | 19:20 |
| mpt | jcastro, I've installed them, but haven't had time to restart yet sorry | 19:21 |
| jcastro | mpt: no worries, I was mulling if the same idea applied to the rhythmbox one would be a good idea | 19:21 |
| Nafai | thanks for the advice mpt | 19:22 |
| mpt | jcastro, Rhythmbox would be another example of one that would be counterproductive to port for Lucid | 19:22 |
| mpt | you're welcome Nafai | 19:22 |
| mpt | jcastro, oh, but that's mostly done isn't it | 19:22 |
| mpt | That's why there's people complaining about the tooltip | 19:23 |
| mpt | Sorry, forgot that, it seems like ages ago :-) | 19:23 |
| jcastro | mpt: at this rate you're basically saying that porting nothing to app indicators is a good idea | 19:23 |
| Nafai | :( | 19:24 |
| mpt | jcastro: gnome-control-center, vino, ekiga, gnome-settings-daemon, gnome-gmail-notifier, xchat all make sense to port | 19:25 |
| hyperair | oh hey so mpt agrees with me | 19:26 |
| hyperair | re tooltips | 19:26 |
| hyperair | gnome-control-center has an application indicator? what does it use it for? | 19:27 |
| mpt | jcastro, a second class should be adjusted to not use the notification area at all | 19:27 |
| 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) | 19:27 |
| mpt | hyperair, Rhythmbox is in the third class -- not necessarily a tooltip, perhaps a better mechanism ;-) | 19:28 |
| hyperair | mpt: what do you mean third class? | 19:29 |
| hyperair | mpt: and i'm speaking from banshee's point of view, which should essentially be the same as rhythmbox in this area. | 19:29 |
| mpt | hyperair, ^^^ | 19:29 |
| jcastro | hyperair: gnome-cc uses it for the typing break thing | 19:29 |
| hyperair | ah typing break. | 19:29 |
| hyperair | i've never used that before. perhaps i should give it a run.. | 19:29 |
| * hyperair flexes left wrist | 19:30 | |
| hyperair | mpt: third class meaning a better mechanism than a tooltip? | 19:30 |
| mpt | hyperair, maybe | 19:31 |
| hyperair | mpt: er wait, what are these classes referring to? | 19:31 |
| mpt | hyperair, categories of applications that have been using the notification area. | 19:31 |
| hyperair | ah | 19:32 |
| mpt | we have two goals | 19:32 |
| mpt | (1) reduce the number of them | 19:32 |
| mpt | (2) make the remainder behave consistently | 19:32 |
| mpt | We get #2 by making them a single set of menus | 19:32 |
| mpt | We're not doing so well with #1 at the moment. | 19:33 |
| 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. | 19:33 |
| hyperair | mpt: in other words, these are more like toolbar icons that have dropdown menus when clicked. | 19:34 |
| mpt | I think it would be useful to brainstorm different ways of showing the track info | 19:36 |
| mpt | It's kind of crazy that music players have been showing it in three different ways | 19:36 |
| hyperair | three? | 19:37 |
| mpt | 1 in the player window itself, 2 in notification bubbles, 3 as a tooltip in the notification area | 19:37 |
| hyperair | i know of the tooltip, what are the other two? | 19:37 |
| hyperair | ah. | 19:37 |
| hyperair | well i think 2 and 3 have their own reasons. | 19:37 |
| hyperair | 1 as well | 19:37 |
| hyperair | it wouldn't make sense to not show the track in the player window. | 19:38 |
| hyperair | notification bubbles are transient and show a change of track | 19:38 |
| 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. | 19:38 |
| mpt | Any two of them you could merge, with a bit of work | 19:39 |
| hyperair | i don't see how #1 could be merged with any of the other two. | 19:39 |
| 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 | 19:40 |
| hyperair | #2 and #3 could be merged, by forgoing notify-osd style popups and showing that tooltip for a brief period when changing. | 19:40 |
| mpt | exactly | 19:40 |
| hyperair | i don't see how #1 and #2's merge can be even considered a solution. | 19:40 |
| hyperair | exactly in the same place | 19:41 |
| hyperair | considering player windows can move all over the place, your notification bubble is going to also move all over the place | 19:41 |
| hyperair | and it's going to obstruct whatever the user is doing | 19:41 |
| mpt | notification bubbles already obstruct some people wherever they are :-) | 19:41 |
| hyperair | notify-osd minimizes that. | 19:41 |
| mpt | but yeah, it would be more likely nearer the center of the screen | 19:42 |
| mpt | This is all just brainstorming, not saying any of these are brilliant ideas | 19:42 |
| hyperair | heh | 19:42 |
| hyperair | right | 19:42 |
| 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. | 19:43 |
| Nafai | what do you mean by mouse feedback? | 19:45 |
| mpt | ditto | 19:45 |
| hyperair | Nafai: middle click to play/pause. | 19:45 |
| hyperair | scroll to change track. | 19:46 |
| Nafai | oh, I see | 19:46 |
| hyperair | mouseover for too-er wait, that's tooltips. | 19:46 |
| Nafai | I never realized that the old rhythmbox thingy allowed that :) | 19:46 |
| hyperair | i don't speak for rhythmbox. i speak for banshee. | 19:46 |
| hyperair | tbh i can't be assed about what happens to rhythmbox really =p | 19:47 |
| Nafai | oh, sorry | 19:47 |
| hyperair | i'm not sure whether rhythmbox allowed that though | 19:47 |
| hyperair | it might have | 19:47 |
| hyperair | i know amarok did during the kde3 days. | 19:48 |
| hyperair | i'm not sure if it still does. | 19:48 |
| hyperair | even exaile allows it somewhat | 19:48 |
| hyperair | i think exaile does volume though | 19:48 |
| === chaotic_ is now known as chaotic | ||
| === chaotic_ is now known as chaotic | ||
| Nafai | jpetersen: Around still? (I realize it is late there :)) | 20:46 |
| Nafai | Or anyone else that might know GtkBuilder or gtk menus in general | 20:47 |
| 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 | 20:48 |
| === sabdfl1 is now known as sabdfl | ||
| jpetersen | Nafai, hi | 21:30 |
| Nafai | Hi jpetersen | 21:31 |
| jpetersen | Nafai, which application is it? | 21:31 |
| Nafai | gnome-bluetooh | 21:31 |
| Nafai | gnome-bluetooth | 21:31 |
| 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 | 21:31 |
| Nafai | er, gtkbuilder file | 21:31 |
| Nafai | and then builds the menu: http://git.gnome.org/browse/gnome-bluetooth/tree/applet/main.c?id=GNOMEBT_V_2_29_91#n361 | 21:31 |
| Nafai | if I try getting at the menu item using gtk_builder_get_object (xml, "preferences"), it returns the GtkAction, not the GtkMenuItem | 21:32 |
| Nafai | And I don't know how to get at the menu item | 21:32 |
| jpetersen | Nafai, ah yes I think you need to get the ui-manager with gtk_builder_get_object (xml, "bluetooth-applet-ui-manager"); | 21:34 |
| Nafai | Ah, I didn't notice the ui manager there | 21:35 |
| jpetersen | and than the widget with gtk_ui_manager_get_widget | 21:35 |
| Nafai | right | 21:35 |
| Nafai | I think I can do that. Thanks :) | 21:35 |
| jpetersen | the path in gtk_ui_manager_get_widget is something like "/bluetooth-applet-popup/preferences" than :) | 21:36 |
| jpetersen | your welcome :) | 21:36 |
| jpetersen | I will leave now | 21:36 |
| jpetersen | good night :) | 21:36 |
| ryanprior | Is anybody working to patch Gwibber to handle Google Buzz before Lucid? | 21:50 |
| jcastro | the | 21:56 |
| jcastro | APIs aren't public yet afaik | 21:57 |
| sanderqd | http://code.google.com/apis/buzz/ seems you can only retrieve updates, and post them from another connected site | 21:57 |
| === MacSlow|capoeira is now known as MacSlow | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!