| lamalex | kenvandine, does anything else need to be done for lp:460286? Do we need to update current installs, or just fix for new? | 01:20 |
|---|---|---|
| lamalex | kenvandine, would it be faster to get in if I made a debdiff? | 01:21 |
| lamalex | wow, the new indicator applet is entirely unnoticable.. | 01:44 |
| lamalex | what happened to the green envelope? | 01:46 |
| vish | lamalex: its still supposed to be there, it would be in humanity theme | 03:08 |
| lamalex | vish, my icons were changed to "ubuntu-mono-light" | 03:09 |
| vish | lamalex: yeah , thats the default | 03:09 |
| lamalex | ok, so that's what im saying | 03:10 |
| kenvandine | hey lamalex | 03:19 |
| kenvandine | lamalex, i was going to look at that patch tonight | 03:19 |
| kenvandine | lamalex, in fact... i am updating empathy to 2.29.91.2 now | 03:21 |
| kenvandine | lamalex, please file your patch in bugzilla too, https://bugzilla.gnome.org/show_bug.cgi?id=610589 | 03:27 |
| ubot4 | Gnome bug 610589 in Notifications "enable notifications when chat is not focused" [Enhancement,Unconfirmed] | 03:27 |
| lamalex | kenvandine, will do | 04:11 |
| lamalex | kenvandine, there's also a branch for lp:206547 that should be looked at. i tried doing git format-patch and applying the patches to lp:empathy, but they don't apply cleanly, unfortunately | 04:12 |
| lamalex | kenvandine, patch sent upstream | 04:14 |
| lamalex | that's the problem with lp and upstream bugs, patches get out of sync easily, and it's more important (for me personally) to see them get into Ubuntu, since that has a more direct effect on me as a user, but of course we want them to get upstream as well.. | 04:15 |
| kenvandine | yeah | 04:16 |
| lamalex | kenvandine, can you go on gtalk and send me an im/ | 04:26 |
| lamalex | im testing that branch to open a new window instead of go to the panel | 04:26 |
| lamalex | kenvandine, is there a wiki page about the session indicator? what "busy"/"away" mean semantically and how applications should behave for each? | 04:55 |
| RAOF | Anyone here? I'd like some idea of where to put the “Undo” button for editing in f-spot's view mode. | 06:07 |
| RAOF | I think I'll plump for “In the toolbar, next to the rotate buttons and before the fullscreen button”. | 06:10 |
| lamalex | RAOF, step to get to where you are? | 06:36 |
| RAOF | lamalex: As in, how does the user get to the editing mode? | 06:36 |
| lamalex | just double click a photo, right? | 06:37 |
| RAOF | Select a photo in the sidebar, change the sidebar to “edit”. | 06:37 |
| lamalex | yeah, that looks like a good place for an undo button | 06:42 |
| lamalex | while you're at it, you should make that sidebar size properly when it loads.. | 06:43 |
| lamalex | it's smaller than the width of the buttons for me | 06:43 |
| RAOF | I'll see what I can do :) | 06:45 |
| lamalex | you da man | 06:50 |
| lamalex | so the thing I don't like about this is that this patch isn't up-streamable since it's line numbers are based on other ubuntu specific patches | 06:51 |
| RAOF | The f-spot patch, or another one? | 06:53 |
| RAOF | patch is generally pretty good at matching the context if the line numbers change. | 06:53 |
| RAOF | That is, after all, one reason why it *includes* context in the first place. | 06:54 |
| lamalex | empathy | 07:01 |
| lamalex | for popping open a window instead of just sitting in the tray | 07:02 |
| RAOF | Unless the surrounding code has changed upstream the patch should apply, just with some fuzz. | 07:03 |
| lamalex | lets hope | 07:03 |
| lamalex | woo! deb built! | 07:06 |
| lamalex | awesome, it works | 07:19 |
| lamalex | RAOF, you still around? | 07:19 |
| RAOF | Yeah. | 07:20 |
| lamalex | can you help me test out this empathy patch a little bit? | 07:20 |
| lamalex | as in talk to me on empathy for 10 mins or so? | 07:20 |
| lamalex | send me requests for IM/Chat/Video/etc | 07:20 |
| RAOF | Yeah, totally. | 07:20 |
| lamalex | merci | 07:20 |
| lamalex | hm, so now it's popping up on top but not stealing focus, I wonder if i should open it minimized? | 07:21 |
| lamalex | or is on top-not focused ideal | 07:21 |
| lamalex | anyone from the design team here? | 07:21 |
| lamalex | RAOF, can you send me a MUC request? | 07:22 |
| RAOF | lamalex: Only if you can tell me how to do that; I've never managed to work out how in Empathy. | 07:23 |
| lamalex | hm, i actually have no idea | 07:24 |
| RAOF | Have you ever recieved a MUC request in empathy? | 07:24 |
| lamalex | i think so | 07:24 |
| lamalex | does anyone know? | 07:25 |
| RAOF | I like that aubergine. Can we have notify-osd's background be aubergine, too? :) | 07:25 |
| RAOF | To make it match the tooltips. | 07:26 |
| lamalex | me too | 07:26 |
| lamalex | I think the problem there is matching all themes | 07:26 |
| lamalex | there are a lot of colors that would look horrid | 07:26 |
| RAOF | Yeah. | 07:26 |
| lamalex | RAOF, can you send me another im? | 07:27 |
| === MacSlow is now known as MacSlow|lunch | ||
| qense | good afternoon | 13:32 |
| qense | sweet! The new theme has landed! | 13:37 |
| qense | jcastro: Is there already a session planned in the UOW for explaining Application Indicators? I could help with answering questions during such a session. | 14:03 |
| Nafai | Good morning | 14:03 |
| jpetersen | Hey | 14:07 |
| Nafai | How are you doing jpetersen? | 14:07 |
| jpetersen | Nafai, I am good. How are you? | 14:08 |
| Nafai | Doing well | 14:08 |
| Nafai | About to dive back into figuring out a app indicator bug | 14:09 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | Nafai, there? | 14:53 |
| Nafai | seb128: Yeah | 14:58 |
| seb128 | Nafai, did we agree that the gnome-bluetooth icon issue was a indicator-application one and that the hacks to unset the icons were not required? | 14:59 |
| Nafai | Yes, I believe so | 15:00 |
| seb128 | Nafai, you cleaning patch still has those changes | 15:00 |
| seb128 | your | 15:00 |
| Nafai | whoops | 15:00 |
| Nafai | dang it, let me quickly regenerate | 15:00 |
| seb128 | on bug #532104 | 15:00 |
| ubot4` | Launchpad bug 532104 in gnome-bluetooth (Ubuntu) "Fix app indicator classification and other minor issues (affects: 1)" [Low,Incomplete] https://launchpad.net/bugs/532104 | 15:00 |
| seb128 | Nafai, that's ok, I can fix that there | 15:00 |
| Nafai | ok, thanks | 15:00 |
| seb128 | Nafai, it's only a chunk to delete | 15:00 |
| seb128 | Nafai, thanks | 15:00 |
| Nafai | :) | 15:00 |
| jpetersen | will be back in a bit | 15:31 |
| jcastro | now that it's not thursday can I get some love on: https://bugs.edge.launchpad.net/ubuntu/+source/indicator-application/+bug/530138 | 16:52 |
| 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] | 16:52 |
| Nafai | I'm kind of stumped so far :) | 16:53 |
| Nafai | been interesting reading gtk and app indicator code | 16:53 |
| tedg | bratsche: Have you looked at the bug above any? Nafai was trying to figure it out, but is having some issues. | 17:00 |
| Nafai | Just learning the stack right now | 17:00 |
| Nafai | (the signals and such) | 17:00 |
| tedg | Nafai: You think it is a shell vs. container thing, right? | 17:00 |
| Nafai | originally I thought so, but then I noticed there is a gtk_menu_shell_add, so I think that was incorrect | 17:00 |
| Nafai | But given that, I'm not sure where the "add" signal is being emitted | 17:01 |
| Nafai | (again, learning how the different parts of gtk work) | 17:01 |
| bratsche | tedg: I don't think so. | 17:02 |
| Nafai | all in all, I think the app indicator code is nice though :) | 17:02 |
| tedg | Nafai: Hmm, okay. Sometimes just grepping through GTK code helps too :) | 17:03 |
| Nafai | Yeah, that's the point I'm at now | 17:03 |
| jcastro | Nafai: if I turn off bluetooth and then I go to turn it on the label still says "Turn Off Bluetooth" | 17:28 |
| Nafai | Oh | 17:28 |
| Nafai | Let me take a look | 17:28 |
| Nafai | ok, I think I've reproduced, I'll see if I can figure out why | 17:34 |
| jpetersen | Nafai, is it using GtkActions? | 18:31 |
| jpetersen | Nafai, than when the label in the action is updated there is no notify::label from the menu item that the label updated (a gtk+ bug in my opinion) I had the same problem in rhythmbox | 18:33 |
| jpetersen | notify::label signal so application-indicator does not know about the updated label | 18:33 |
| jpetersen | Nafai, I think we should a workaround to application-indicator | 18:42 |
| jpetersen | add a workaround I mean | 18:42 |
| jpetersen | Nafai, I will look at it on Monday | 18:50 |
| jpetersen | Have a nice weekend all | 18:50 |
| Nafai | Sorry I missed jpetersen | 18:56 |
| === jono_ is now known as jono | ||
| qense | tedg: Why was app-indicator-enum-types.h left out of the libappindicator_SOURCES? | 19:11 |
| tedg | qense: I forgot? :) | 19:12 |
| tedg | qense: I don't know of a reason other than it'd create a recursive generation of that file. | 19:12 |
| tedg | qense: No wait, that should be fine as it's built from headers. | 19:12 |
| tedg | qense: Is it causing an issue? | 19:13 |
| qense | tedg: I think it's making the *get_type() functions inaccessible from inside the library | 19:13 |
| qense | tedg: the types.h file is in {libappindicatorinclude_HEADERS} but not in {libappindicator_headers} | 19:14 |
| qense | and it is the latter that gets added to SOURCES | 19:14 |
| tedg | qense: I don't think it should do that. It doesn't limit the ability for linking. | 19:14 |
| tedg | qense: What's the error you're getting? | 19:15 |
| qense | tedg: So it shouldn't matter? | 19:15 |
| tedg | qense: I don't think so. | 19:15 |
| qense | OK, then I'll remove it and see what happens. | 19:15 |
| qense | The error is already lost in the scrollback as I'm now chasing other issues. | 19:15 |
| qense | tedg: Do you happen to know when 'category-nick' is returned as the value's nick, rather than 'CategoryNick'? | 19:16 |
| qense | tedg: Somehow "category_enum_value->value_nick" returns a 'category-nick' kind of nick. | 19:17 |
| qense | (category_enum_value was obtained using g_enum_get_value()) | 19:17 |
| tedg | qense: I'm not remembering all the details, but we had an issue with this. That's why we did the "big sed" in the Mono bindings to clean it up. | 19:17 |
| qense | I made it less big. | 19:18 |
| qense | but still | 19:18 |
| tedg | qense: I think the Camel Case one might have broken something else. | 19:18 |
| qense | I need to get the CamelCase somehow, otherwise the lru thing is broken. | 19:18 |
| qense | tedg: "@valuenick@ | 19:43 |
| qense | A nick name for the enum value currently being processed, this is usually generated by stripping common prefix words of all the enum values of the current enum, the words are lowercase and underscores are substituted by a minus (e.g. the-xvalue)." | 19:43 |
| qense | That variable is being used to generate enum-types.c | 19:44 |
| qense | afterwards you replace it with sed in the Makefile | 19:44 |
| qense | tedg: Apparently "lower-case" seems to be the desired format for nicks. | 19:44 |
| qense | or at least GNOME feels that way | 19:44 |
| tedg | qense: Yes, and I think that changing it broke something in GNOME. | 19:45 |
| tedg | Well, more correctly, GTK. | 19:45 |
| tedg | So that's why we tried to change it just for the Mono bindings. | 19:45 |
| qense | tedg: it is still written like CamelCase in the generated enum-types.c | 19:46 |
| qense | because there is also a sed in src/Makefile | 19:46 |
| qense | grep "application-status" src/* | 19:46 |
| qense | src/Makefile: -e "s|\"application-status\"|\"ApplicationStatus\"|" \ | 19:46 |
| qense | src/Makefile.am: -e "s|\"application-status\"|\"ApplicationStatus\"|" \ | 19:46 |
| qense | src/Makefile.in: -e "s|\"application-status\"|\"ApplicationStatus\"|" \ | 19:46 |
| qense | tedg: Shall I remove the sed? | 19:47 |
| tedg | qense: Hmm... | 19:48 |
| qense | tedg: If yes, should I remove the 'DISTCLEANFILES' as well, or is that for something differently.? | 19:49 |
| tedg | If there's no need for the temp file, sure. | 19:49 |
| tedg | It should go completely away. | 19:49 |
| qense | tedg: it will make appind crash | 19:49 |
| tedg | But, I'm curious why it was done twice. | 19:49 |
| qense | on all systems | 19:49 |
| qense | please take that into account | 19:49 |
| qense | we'll have to purge the lru file | 19:49 |
| tedg | ? | 19:49 |
| tedg | I'm confused. | 19:50 |
| qense | Currently the categories are saved in .config/indicators | 19:50 |
| tedg | Yes | 19:50 |
| qense | using their nick | 19:50 |
| qense | When we'd remove the sed the nicks would change | 19:50 |
| tedg | Ah, yes. We don't want to do that. | 19:50 |
| tedg | The nicks are also importnat as they're what's in the KDE spec. | 19:50 |
| qense | tedg: CamelCase is required? | 19:51 |
| tedg | qense: Yes. | 19:51 |
| qense | ok, then we will have to replace them | 19:51 |
| qense | unfortunately there is no glib-mkenums thing for that | 19:51 |
| qense | so we will have to use sed | 19:51 |
| qense | glib-mkenums just offers @VALUENAME@ and @valuenick@ | 19:52 |
| qense | the first is LIKE_THIS, the second like-this | 19:52 |
| qense | tedg: however, you can specify the nick by adding /*< nick=the-last-value >*/ after the APP_INDICATOR_CATEGORY_THE_LAST_VALUE line in the enum definition. | 19:55 |
| qense | I think we want that. | 19:55 |
| qense | that should magically solve all the problems we have | 19:56 |
| tedg | Hmm, okay. I didn't know that about mkenums. | 19:57 |
| tedg | I'd be nice to get rid of the sed. | 19:57 |
| qense | yes | 19:57 |
| qense | it should set some things straight elsewhere as well | 19:57 |
| qense | tedg: However, all I'm doing in the Makefile for the Mono bindings in my branch is replacing the variables with their meanings, using sed. | 19:58 |
| qense | That is because somehow the defines aren't replaced when the binding xml source is generated so the cnames are still variables for some properties | 19:59 |
| tedg | qense: Yeah, that's kinda annoying. | 20:01 |
| tedg | qense: It's because the mono scanner doesn't compile anything. | 20:02 |
| qense | tedg: the Python bindings aren't using CamelCase for the nicks, was that done on purpose? | 20:06 |
| qense | plus: were you aware of all these dpkg-shlibdeps warnings: <http://pastebin.ubuntu.com/389171/>? | 20:07 |
| tedg | qense: Yes, I'm unsure why that happens, as we do use GTK which links to all those. I don't understand why it would think that is an error. | 20:09 |
| qense | tedg: it is defined in .defs like that | 20:09 |
| qense | I couldn't find anything updating it, so I assume it was done manually | 20:09 |
| qense | or generated a while ago | 20:09 |
| tedg | qense: Generated a while ago may be more the case. | 20:10 |
| qense | tedg: load_from_file() in application-service-lru.c always returns FALSE, even the last return statement returns FALSE. Is that desired behaviour? | 20:29 |
| tedg | qense: Yes, it's an idle function, so that makes sure it doesn't run again. | 20:31 |
| qense | ah | 20:33 |
| qense | tedg: Could you help me with the following two error messages? I get "/build/buildd/glib2.0-2.23.4/gobject/gsignal.c:2268: signal `destroyed' is invalid for instance `0x11910a0'" and "Indicator Item property 'visible' unknown" in ~/.cache/indicator.log. Do you know what raises them? I couldn't find the error message in any library or indicator. | 21:58 |
| tedg | qense: Glib is raising them. | 21:59 |
| === rickspencer3_ is now known as rickspencer3 | ||
| tedg | qense: I'd say that someone is looking for a destroyed signal on something that isn't an object. | 22:00 |
| tedg | qense: Perhaps it was free'd first? | 22:00 |
| tedg | qense: Can you run under gdb? | 22:00 |
| qense | tedg: I'll try to, I hope Indicator Applet won't interfer. | 22:00 |
| qense | tedg: the service exits without the applet on the panel and with the applet on the panel you can't separately launch the service. | 22:01 |
| qense | tedg: I'll look for a untimely g_free() | 22:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!