[02:19] hello i need some help with my python script and the indicator applet [02:19] i can't seem to get the applet to recognize that my script is running [02:19] it only shows the arrow next to the entry when i run the script directly from the command line [02:34] never mind, i had the wrong path for the .desktop file [08:30] It seems the libappindicator bindings in Maverick are bugged [08:30] I had to manually edit them to make them work [08:30] er [08:30] Vala bindings, I mean. The .vapi file [09:41] lucidfox: that's quite possible, what have you changed? [09:41] kklimonda> I'll post a patch against the Maverick version in a moment [09:42] the patch is against the .vapi file, though, and it's autogenerated [09:45] lucidfox: it may still help [09:51] kklimonda> bug #632996 [09:51] Launchpad bug 632996 in indicator-application (Ubuntu) "Vala bindings for libappindicator are incorrect (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/632996 [09:51] ah, yes.. [09:53] this is what you get when you don't follow GObject naming scheme [09:56] Well, "../src" was just developer oversight, evidently :) [09:58] meh, whole API breaks all conventions of GObject so gobject introspection generates garbage and so does vapigen.. [09:58] hi chaotic [09:59] you have _get_menu and _set_menu that take/return GtkMenu argument and then you have a menu property that is a string.. [10:00] well yes, that's odd [10:00] same with status [10:01] and icon - you have _get_icon and _set_icon but property is icon-name [10:01] I've complained about it months ago [10:01] apparently not loud enough [10:02] and now we are probably stuck with this excuse for an API anyway [10:06] lucidfox: for now the only thing to do is to ship your own .vapi with project [10:06] I [10:07] I'm going to poke tedg when he's online about it but, as I've written in my comment, fixing it is not trivial. [10:09] Well, we all know what happens with new GUI elements [10:09] First they appear in external libraries. Second they appear in GTK, the GTK developers do them right, and the external libraries are deprecated. :p [10:10] Is there no way to provide hints for gir/vapigen to generate the correct bindings? [10:14] lucidfox: not that I know of [10:14] lucidfox: not for this kind of problems [10:14] if bindings weren't generated from .gir you could do basically everything in the .metadata file [10:15] but Ayatana devs believe it's wrong way of doing that because it can't be easility tested when you do changes to the library. [10:15] so they have opted for .gir [10:16] the poor API has been one of the reasons the inclusion of libindicator into Gtk+ has failed. [10:16] Then the GTK developers should write GtkPanelIndicator or something that offers a better API for this :p [10:17] that's not really how things work. [10:17] there are no Gtk+ developers per se after all.. [10:17] ...no wonder it's stagnating then :( [10:17] indeed [10:17] but the situation is getting better recently. [10:18] still if anyone were to provide GtkPanelIndicator it would have to be Ayatana [10:19] and those who provide code would have to justify why do we need a duplicate of GtkStatusIcon [10:19] Pah! Just deprecate GtkStatusIcon! :p [10:19] I think GTK is architecturally superior in its core concepts, but... Qt has Trolltech/Nokia's corporate backing, and it really shows. In just about everything :( [10:20] well, I agree that Gtk+ is part of a better platform. [10:21] and it's written in C [10:21] who in their right mind would even touch C++... ;) [10:21] yeah :S [10:22] I would actually like to see more application developers moving away from C to Vala, Python or C#, and see larger parts of the core platform stack rewritten in Vala [10:23] lucidfox: Vala, in my opinion, while a great idea, is still a too thin wrapper over C [10:24] iainfarrell: ivanka: do I need to move to London in order to speak with chaotic? :) I guess I'll rent a house :D please poke him *live*! [10:24] Well [10:24] I've don esome cool updates [10:25] if I wanted to attract new developers to a "sexy" platform to write applications for, I'd point them to Mono/Gtk#, but the very mention of Mono is enough to cause half the community to go RAWR MICROSOFT TAINT [10:25] cimi: I am working at home today and I think they are doing a fire alarm test in Millbank which means walking all the way down and then up again [10:26] lucidfox: do we really need half a dozen of different VMs running on our desktops? :/ [10:26] Hardly half a dozen [10:27] One CLI to rule them all [10:27] lucidfox: every time I see how much ram do gwibber use.. or even the smallest applet I'm irritated. [10:27] Well, Python is just :S [10:28] writing in python or mono seem to disable something in programmers' minds and they stop tracking how much memory do their applications use. [10:28] or it's just the VMs that are written that way [10:28] Python has its legitimate uses as a scripting language, but writing serious desktop applications in it just sounds odd to me [10:28] lucidfox: that too is a problem - but the fact that they hide memory managment doesn't help. [10:29] More importantly, to attract new developers, I think providing better toolchains and IDEs is more important than providing better languages [10:29] lucidfox: meheheh.. :/ [10:29] Qt has the right idea with Qt Creator [10:29] ivanka: oh thank you boss ;) [10:30] a good IDE built around clang with great profiling tools, support for valgrind, good gdb integration, with a nice GUI.. we can dream of it ;) [10:30] and *not* using autotools. [10:31] meh, I got used to autotools. [10:31] sure, they ain't pretty [10:31] You did, but requesting new developers to understand the arcane syntax is just too much, I think [10:32] not just syntax - all the arcane gotchas that come with it [10:32] cimi: hehe [10:32] not to mention that a build system based on shell scripts is unportable by design [10:37] "@Andr?s, why would Gnome want to switch to CMake? From my experience with it, it?s a pretty rubbish system? I had a lot of trouble with it. For example, it couldn?t even do pkg-config without a 3rd party script." [10:37] Epic facepalm [10:37] Cimi: ok, wassup with the resizer? [10:37] Cimi: hi, btw ;) [10:40] davidbarth: what about the cody's patch to add resize grippers without needing to add them in the statusbar? [10:43] Cimi: i don't think he has it, or that it is ready [10:43] davidbarth: so it won't land in maverick? [10:44] Cimi: plus it's past feature and UI freeze now [10:45] Cimi: let's check with bratsche once he wakes up for the level of complexity, but i doubt it's that easy, so which means a risky change to propose at that stage [11:06] chaotic: ? === bilalakhtar is now known as cdbs === cdbs is now known as bilalakhtar === bilalakhtar_ is now known as bilalakhtar === MacSlow is now known as MacSlow|lunch === agateau_ is now known as agateau === MacSlow|lunch is now known as MacSlow === rgreening_ is now known as ghost === ghost is now known as rgreening [15:06] Cimi, davidbarth: I have a patch somewhere (forgot what computer it's on now), but it hasn't received much testing or review. I seriously doubt seb128 would accept such a patch at this point, and I kind of wouldn't blame him. :) [15:06] ok [15:06] I can look for the patch though. [15:07] And then we can figure out what we want to do with it. [15:08] I found my original patch, but this isn't the latest one: https://bugzilla.gnome.org/show_bug.cgi?id=591721 [15:08] Gnome bug 591721 in gtk "provide a way for all resizable windows to have a resize grip" [Enhancement,New] [15:08] bratsche: putting it in the same gtk daily build as the one that i'd like to have for argb [15:09] There was one that also had kind of a weird hack to either GtkScrollbar or GtkScrolledWindow, and I guess I never posted it on bugzilla. I'll try to find it. [16:47] chaotic: ? [17:01] Cimi: hi, been in meetings === oubiwann is now known as ouibiwann === ouibiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === funkyHat_ is now known as funkyHat