[09:55] good morning [10:00] good morning sense [10:18] bratsche: You're looking after Application Indicators while Ted is on holiday? Does that also include merge requests? C10uD and I worked yesterday on implementing icon theme path changes and I filed a merge request for it, but I was wondering whether anyone will look at it for the next few days. I would be happy if the change -- when accepted -- could land before Alpha 3 because I do think that such important changes to the library need to be tested we [10:18] ll enough. [10:19] https://code.launchpad.net/~indicator-applet-developers/indicator-application/trunk/+activereviews [10:19] whoops, wrong lnk [10:19] https://code.launchpad.net/~c10ud/indicator-application/runtime-themepath-change/+merge/30695 [10:20] sense can i have a look at this too [10:20] Yeah, I can take a look at it. I'm in the middle of debugging some X crashiness first though, so it may be awhile before I look at it. [10:20] it might touch something that I'm currently writing a patch for [10:20] Awesome [10:20] Thanks klattimer! [10:20] klattimer, bratsche: OK, that would be great! [10:20] sense: can I find a diff? [10:20] I just want to know what's differend ;) [10:21] https://code.launchpad.net/~c10ud/indicator-application/runtime-themepath-change/+merge/30695 [10:21] ah missed that ;) [10:22] appears to avoid completely what I'm doing [10:22] so I have no objections [10:22] bratsche: The changes do touch the KDE spec XML file to add a new signal there. How bad is that? [10:22] good [10:22] klattimer: Are you working on submenu related isues? [10:26] sense: no, getting absolute paths to render icons [10:26] for ibus [10:27] ah, something long requested, but always refused [10:30] sense: I'm hiding the API away [10:30] no sense publicising it [10:31] ok [10:31] We don't want every app to use fancy custom icons. [10:36] ibus menus stopped responding... sudden random heisenbugs :/ [10:39] You mean that it doesn't react to activate events anymore? I'm having the same issue with my work on making later added submenus work. [10:40] :/ [10:40] is there a bug filed? [10:42] I'm not sure what causes it, so I haven't filed a bug. It may be my own fault. I get some complaints, so it seems, that some pointer is not a valid GtkMenuItem. [10:42] There is a bug for the submenu thing, if you wanted to know that. [10:55] sense it's just not responding to activate events [10:55] and therefore I can't change the icon, and therefore unable to test my patch :( [10:55] really irritating [10:56] but the other indicators work fine [10:56] :/ [10:56] klattimer: Great... I'll try to look into my activation issues to see what's causing it, maybe it will help you too. [10:56] klattimer: Maybe something wrong in the declaration of the menu? [10:56] not sure yet [10:57] I'll have to look inside of the indicator applet itself [10:57] so far I've only tried testing changes to libindicator [11:06] klattimer: I'm afraid PyGTK is somewhat broken on Maverick, maybe that's causing problems. [11:06] >>> menu = gtk.Menu() [11:06] __main__:1: Warning: invalid (NULL) pointer instance [11:06] __main__:1: Warning: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed [11:06] Example ^^ [11:07] bratsche: Do you know of any recent update that might have done this to PyGTK? [11:11] :( [11:11] is this pygi related perhaps? [11:12] I thought we weren't going to use that this release yet. (PyGI has been integrated into GObject/GLib and the separate package isn't necessary anymore in Maverick, though.) [11:13] k [11:13] I don't know what's being used tbh [11:13] so I'm just throwing out a suggestion ;) [11:16] bratsche: Also, when importing gtk in Python you get deprecation warnings about "pygobject_register_sinkfunc". [11:20] hey, i've said it before, but I was wondering about what to do about some sort of indicator to show the status of caps lock etc for keyboards that don't have LEDs [11:20] i'd like to write it myself, but I don't really know where to begin [11:21] dutchie: You need to have something running in the background that periodically checks and updates the indicator. You could check the code examples at for code to start with. [11:21] i'm reading that now [11:21] so i should create a non-gui program with an application indicator? [11:21] and not find a system indicator to hook in to? [11:22] That could be a better solution, but I'm not sure you can dynamically extend stuff, you'll probably have to write a patch for the Keyboard Indicator. [11:22] dutchie: you may as well just write a small python app to create the indicator [11:22] yeah, that's what I was thinking of [11:22] mpt: What would you think of an optional Caps Lock status indicator in the Keyboard Indicator? [11:29] bratsche: pygtk is teh bork [11:29] :( [11:29] Maybe this will convince people to stop using fucking Python. ;) [11:29] * bratsche radiates hate [11:29] :) [11:29] don't slate the snake [11:36] hmm, something isn't quite making sense anymore [11:36] the status icon can't load the image file [11:36] ... nothing changed in the status icon [11:36] Is iBus using Python? [11:36] I think pygtk has gone on holiday or something [11:36] sense: the applet does [11:36] Yeah, so it seems. [11:37] Something broke it. Maybe it needs to be rebuilt against libgtk+2.0? [11:38] sense menus work on the status icon variety of ibus, so I don't think it's necessarily the menu [11:38] i think it's probably dbus menus for the indicators which are mostly broken [11:38] but pygtk has other issues too [11:38] sense, interesting, but I think it would be more effective inside fields where it would help. For example, in password fields. [11:38] lets see what magical updates come today [11:38] hi klattimer [11:38] gtk didn't change recently neither did pygtk [11:39] dutchie: ^^ [11:39] hi mpt [11:39] seb128: Then why would it suddenly start not working? [11:39] mpt I think sense was referring to the case stated that when there are no on-keyboard indicators [11:39] which I think is a valid reasoning to have them visible always [11:39] reminders in password fields for sure [11:39] but it's difficult sometimes to spot if you've got a lock on [11:40] even more so if theres no light :) [11:40] sense, do you use some cracky ppa? [11:41] seb128: No, just regular Maverick GTK+. [11:41] The strange thing is that the problems have only started yesterday evening or this morning, without any update. [11:42] sense pretty much the same thing here [11:42] seb128: apart from a new GTK+ release [11:42] try restarting. ibus is full of transient errors. [11:42] and ive also rebooted several times [11:42] okay, so it's not so transient this time. =p [11:42] sense, gtk in maverick just changed the appmenu proxy code [11:42] hyperair: it's not just iBus, it's also the code 'import gtk; menu = gtk.Menu()" [11:42] kenvandine, ^ [11:42] seb128: yes, I saw that. That's why I find it so strange. [11:43] brb [11:43] http://pastebin.ubuntu.com/467926/ [11:44] * kenvandine looks [11:44] sense: kenvandine running the above test here [11:44] I get the same sinkfunc errors [11:44] but don't get the menu error after menu = gtk.Menu() [11:44] Those sinkfunc errors have been there for a long while, though. [11:44] no errors here [11:44] besides the sinkfunc errors [11:44] Maybe I broke my installation somehow. [11:44] sense have you tried updating again today? [11:45] yes [11:45] either way I'm not getting any response from the menu's in python [11:45] but am in C [11:45] http://pastebin.ubuntu.com/467927/ is a longer piece of errors [11:45] klattimer: You think it could be related to localisation? [11:46] sense, so are all appmenus broken for you? [11:46] I couldn't say [11:46] kenvandine: No, that's not the case, strangely. [11:54] sense, ok i thought maybe it was the python bindings [11:55] but i just tested that, worked fine here [11:56] kenvandine: I'll do reïnstall, maybe I broke something. [11:57] kenvandine: I'm definitely having a problem in that an activated signal emitted on a menu doesn't cause the callback to fire in python application indicators [11:57] I just checked through the code, and it's definitely broken somewhere :/ [11:57] klattimer, ok, let me try a simple test here [11:58] kenvandine: Same thing here. [11:58] but only in submenus [11:58] ok, i have a test [11:58] ah! [11:59] klattimer, in a submenu? [12:00] Hmm [12:00] Liferea upstream has offered me the possibility of joining the team so I could maintain indicator support there. [12:01] kenvandine, klattimer: I am working on lp:~sense/indicator-application/submenu-later, but I think those changes should just work. [12:01] LucidFox: Good news! [12:05] kenvandine: well in the main ibus menu [12:05] so not just submenus [12:06] Here it is just the submenus of Deluge, nothing in the main menu. [12:14] sense, klattimer: well my test in python with submenus worked [12:15] kenvandine: can you test ibus [12:15] * kenvandine is just glad to know the python bindings aren't broken [12:15] the existing code should bork in the same way [12:15] klattimer, yeah, but after lunch [12:15] :) [12:15] bbiab [13:07] klattimer, ok, which package are you working on? [13:08] ibus-gtk === jurgen is now known as jurgenf [13:47] kenvandine: any luck reproducing? [13:48] yeah [13:48] diagnosis? [13:48] trying to figure out how to run this locally [13:48] to debug [13:49] run what? [13:49] ibus [13:49] yeah [13:49] or the applet? [13:49] the applet [13:49] ah [13:49] got tips to save me time? [13:49] /usr/lib/indicator-applet/indicator-applet in a terminal [13:49] then add it to the panel [13:49] the output will appear in the terminal [13:49] oh... not that part [13:49] then run ibus-daemon [13:49] the ibus indicator iteself [13:50] i have the applet... but i want ibus-daemon to run from my checkout [13:50] not from the package [13:50] oh [13:50] cant you just package it, install it and run it [13:50] that's what I do [13:50] running ./bus/ibus-daemon gets all the python imports from the installed version [13:50] i want to modify it in my checkout and run it locally [13:50] and ideally even run it in a debugger [13:51] it isn't obvious how to run it... setting the PYTHONPATH seems to get ignored [13:51] :/ [13:51] well, maybe it is working [13:51] well... working meaning running the code i think it is [13:52] ah, ok... [13:52] it is getting my PYTHONPATH [13:52] now to figure out why it doesn't get signals [14:10] kenvandine: let me know if you have any luck, this is blocking me now [14:10] i have a patch ready, I think but can't test it [14:10] klattimer, i think it has nothing to do with appindicator [14:11] the fallback doesn't get activate either [14:11] dbusmenu? [14:11] this thing is pretty crazy... very complex setup for a few dynamic menus [14:11] no... in ibus-gtk [14:11] so i got rid of the import appindicator [14:12] so it goes in the notification area instead of indicator-applet [14:12] and? [14:12] for me in the notification area the menu's worked [14:12] and the menu from the StatusIcon doesn't send the event either [14:12] oh dear [14:12] we've got ourselves a nasty one here [14:13] :/ [14:17] klattimer, yeah i removed that appindicator patch from the package completely and it still doesn't work [14:18] oh... damn [14:18] they do work from the package without the patch [14:18] but not when i run ibus-daemon from the source directory [14:18] klattimer, i don't think this is a problem coming from dbusmenu or appindicator [14:19] just the patch needs work [14:19] somehow we aren't wired in right [14:19] to get the signals [14:19] might be that we set_enabled somewhere to the wrong thing and it never even emits the signal [14:23] klattimer, look at the code in language.py with our patch applied [14:24] all the stuff that emits the signals [14:24] ? [14:24] i bet there is something simple in there that is causing the problem... and of course the code is overly complex for what it does [14:25] ui/gtk/languagebar.py [14:25] that seems to be where it emits those signals [14:25] ok [14:25] I'll take a look [14:25] self.__about_button.connect("clicked", self.__about_button_clicked_cb) [14:26] so on clicked, it calls self.__about_button_clicked_cb [14:26] and in that method, it emits the signal [14:26] actually, self.__about_button_clicked_cb isn't even getting called [14:27] yeah [14:27] the signals aren't called at all [14:27] they're just never emitted [14:27] i was thinking the stock signals might be getting there, but the ones added aren't emitted [14:27] but yeah, we aren't even getting those [14:28] looks like pygtk [14:28] dont you think? [14:28] ok, well i have a suspicion [14:28] it's dbusmenu [14:28] heh, I thought that earlier [14:29] the menu items are ToolButtons [14:29] wait... maybe languagebar.py is ignored in our case [14:35] klattimer, well i don't know enough about dbusmenu, but my suspicion is these menu items are made up of ToolButtons [14:35] and maybe the signals that ToolButtons use aren't being handled via dbusmenu [14:36] i could be way off, this code is a mess [14:39] :/ [14:39] i'll poke around a bit more [14:42] kenvandine: the ToolButton isn't used in the menu [14:42] ok [14:42] just straight forward ImageMenuItems and MenuItems [14:44] from what I can see it's a bog standard MenuItem/ImageMenuItem which hooks its activate signal into a few callbacks [14:44] the callbacks never get called [14:44] that means it must be gobject/gtk bindings level [14:44] surely [14:45] ! [14:46] or possibly dbusmenu not emitting the signals back to the indicator correctly [14:46] either is possible I suppose [15:06] klattimer, ok... so it isn't pygtk or dbusmenu [15:06] i put a break point in panel.py, in the __create_im_menu method [15:07] at the end of the method, right before "return menu" [15:07] if i do a menu.show() right there, but not let the program continue [15:07] it sends the right signal when you click on the menu items [15:08] but if i let it continue, and return menu [15:08] it gets hosed [15:08] so i think it isn't that the signal isn't getting emitted, but the menu items aren't connected to them anymore [15:08] klattimer, so i hope that helps :) [15:12] hmm [15:12] that's bizarre [15:32] well I've written a python indicator test case [15:32] and the activated signal is fired in that [15:33] this is a problem with ibus :/ [15:33] *shit* [15:41] kenvandine: I think I found the problem ;) [15:41] using menu.add instead of menu.append [15:41] replacing all occurrences appears to fix it [15:42] oh, no it doesn't [15:42] :/ [15:42] it may have worked once just on it's own [15:42] :/ [15:43] this bug has me beat :/ [15:47] klattimer, something is making it lose the connect to that signal [15:47] i think the signal is still coming, but the widget isn't hooked up to it anymore [15:47] but i don't know why [15:48] i can make it work 100% of the time from in a debugger :) [15:48] once it returns the menu from the __create_im_menu method, it no longer listens for that signal [15:48] but as long as i am stopped there it gets it [15:53] kenvandine: that makes no sense though [15:53] as it needs to go on to add it to the indicator [15:54] no, it is already in the indicator there [15:55] i didn't go back far enough to see when it is getting added to the indicator [15:55] but i am seeing it there [16:17] hmm, then surely it's a double add [16:17] ;) [16:17] I think [16:19] ivanka: We still need more people for the trips during GUADEC if we want them all to continue. Are you, or is someone you know, interested in one of the things listed at ? [16:20] kenvandine: how could it already be added, menu is created in __create_im_menu [16:20] and it doesn't add the menu to the indicator [16:22] must be added somewhere else then... [16:23] nope [16:23] only in __appindicator_update_menu [16:23] after __create_im_menu os called and the menu is created [16:23] then other items are appended to the menu, and it's set [16:23] well, if i stop it there with a break point and do a menu.show() [16:24] so I can't see how not returning the menu can fix it [16:24] it starts getting the signals [16:24] hmm [16:24] it doesn't fix it... [16:24] maybe we need to show the menu [16:24] i can only make it work if i stop it with a breakpoint [16:24] or the menu items before returning [16:24] no... i added it there [16:24] if you let it past that point, even with showing the menu [16:24] it doesn't get the signals [16:24] something happens to it after that [16:24] maybe it gets created a second time [16:25] and the second one isn't connected [16:25] brb [16:52] kenvandine: I fixed it [16:52] you need to call show on each menu item before adding it to the menu [16:52] then the signals seem to stay attached [17:03] ah! [17:04] klattimer: In that case this occurs in libappindicator. I know there is somewhere a check for visible menuitems. [17:45] Hi, I'm looking to get involved in Ubuntu development. Your website said Papercuts is a great place to start. [17:45] I was wondering what I needed to do to get started with this group> [17:45] ? [17:46] bugs.launchpad.net/hundredpapercuts [17:47] kelelsai, you should talk to vish [17:47] thanks! [17:47] I'm registering at the link provided and will talk with vish [21:19] im a little confused. If I'm working on fixing bugs do I need to be packaging everything up? [21:19] or is there a different team that does that? [21:19] it doesn't matter to me either way. Just curious [21:20] if you can stick a debdiff to the bug, it's better. [21:20] ok, thanks [21:20] otherwise someone else needs to drop by and stick a debdiff to the bug