Hey Christian, about Galago, (you already know about this but) I prepared the beginnings of the Python language binding and am planning to integrate Gossip with this (but the Gossip developers are of course welcome to be ahead of me). I hope all instant messengers will consider checking out this Galago as I’m foreseeing your framework to be used as one of the (many necessary) key elements to make my dream about Utopia come true. Don’t underestimate the importance of your framework. I do believe in it.
And let those people who believe we should talk to their whatever instant messenger client directly, think what they want. Do they really believe we (at Evolution, as I’m a contributor) want to talk to every single messenger available using a huge amount of EPlugins that are all to be configured by the end-user? Galago is the way to go! And we do want presence notification support in Evolution. Really, we do.
I hope the KDE messengers will also be interested. Perhaps even the Win32 ones as for example Evolution is coming to your Windows systems sooner or later. Let’s show the world that we do can play nice and all work together. Galago might be one of those nice framework components to achieve this goal.
I just wished an organisation (like fdo or whatever) would have persuaded the other free software developers to start supporting a framework like Galago. What if they would have, after consideration by for example an elected board, steered the developers of messengers to actually start integrating with this technology? Wouldn’t that just work better than this anarchic mess? I do understand that we, free software developers, don’t want to listen to leadership or steering committees. But lets face it people, we are becoming a group of insignificant childish anarchists if we don’t.
Oh yeah, lets all start looking in our own directions and be ignorant to each others technologies and infrastructure. Lets make this stupid situation worse and play the game with nothing but our egos. That isn’t going to get us closer to our goals! That won’t make it more easy for the salesmen to one day say: “Hey it doesn’t matter whether you, the customer, runs KDE or GNOME. We can develop using our way and our employees and that will just work seamlessly on both major platforms”. In stead of having to ask the customer: “Do you run GNOME or KDE”, and depending on the answer tell the customer: “Oh I’m sorry, we don’t have developers for that platform, we can’t help you”.
In fact is this “ego thing” making the entire opensource and free software desktop community (me included) look insignificant. No really I’m serious about that! For people who don’t know how most GNOME and KDE developers think, please note that most developers don’t want this at all. When asked (and I do ask the others frequently) most think working together professionally is very important. And those who don’t can probably be easily convinced with some beer at meetings like GUADEC.
So what are we waiting for? The holy grail of the free desktop? Time? Lets go get some beer!
Can’t wait for your integration of galago in gossip and the python bindings, I was waiting for both of them.
Well, nice dream. But I seriously doubt that galago will make it come true.
>I hope the KDE messengers will also be interested
You are aware of KIMProxy, aren’t you? And that it is, unlike Galago, quite mature and actually used by real applications? Seriously, do you expect KDE developers to throw their _working_ stuff out of the window just to adopt some upstart system doing exactly the same, but not as tested and mature? For what reason? Galago also has another flaw – it is based on C + pseudo-OO hack (glib). Exactly this kind of API that most KDE devs abhor. But don’t just believe my words, please come to #kde-devel and try to find even one person that want to replace KIMProxy with Galago.
>I just wished an organisation (like fdo or whatever) would have persuaded the other free software developers to start supporting a framework like Galago.
Transcript: I know that I can’t beat competition with high quality code and features so there should be some kind of organization to force Galago down everybody’s throats.
Idea that if your library is hosted on fd.o then it automatically becomes standard is quite crazy. I really miss the days when fd.o just set common file standards instead, because now it looks more like bunch of developers with swollen egos trying to push their agenda.
>But lets face it people, we are becoming a group of insignificant childish anarchists if we don’t.
Well, if you want to give them (us?) give orders then first pay them.
> Lets make this stupid situation worse and play the game with nothing but our egos.
Funny, it was you who ignored already existing solution to that particular problem and decided to create new system. Nope, you just went and made it again from scratch without thinking about compatibility and interoperability. Now, for sake of interoperability between desktop environments, you want _others_ to abandon their solution, without even proving that you done it better? Wow, talk about big ego and heavy NIH syndrome. Careful avoiding any mention of KIMProxy will not make it go away, because in contrary to Galago it is actually used by applications.
In fact, Galago was around first, technically.
And KIMProxy is more directly tight to the KDE platform and certain types of things.
Perhaps you’ll hear more about Galago versus KIMProxy sooner or later. You might be supprised, Allen.
But please talk to Christian Hammond about Galago. I didn’t develop Galago.
> In fact, Galago was around first, technically.
Looks like (judging from date of initial import of KIMProxy and date of registering Galago project on sf.net) that there was only 6 days of difference :-)
>And KIMProxy is more directly tight to the KDE platform
From KDE-specific things I see only _optional_ dependency on KABC, but I’m sure it can be replaced with generic addressbook interface just like dependency on evolution was removed from Galago. It is based on Qt of course but then Galago is based on Glib so situation is quite similar. For message busses – as usual DCOP vs DBUS and none is universal (and in contrary to some rumors there is no decision about using DBUS in KDE4 – see "KDE 4 Goals" page in kde wiki if you don’t believe). From my point of view it looks like KIMProxy is as KDE-specific as Galago is GNOME-specific.
>Perhaps you’ll hear more about Galago versus KIMProxy sooner or later. You might be supprised, Allen.
I would love to be surprised because my crystal ball shows me grim future :-) I think that Galago and KIMProxy (and other desktop related technologies) will continue to drift apart and increase integration with their respective DEs.
> I didn’t develop Galago.
Yeah, my mistake. Looks like I was barking at the wrong tree :-)
"I think that Galago and KIMProxy (and other desktop related technologies) will continue to drift apart and increase integration with their respective DEs."
That would be sad. I will be one of the desktop developers (at the GNOME side, that is true) who will try increase integration and who will try persuading others to start working together.
The thing is, Allen, that we aren’t at war. And both the KDE and GNOME folks share the same goals.
Why shouldn’t we work together? Because of our egos?
I thought the free software and opensource communities where trying to make a difference in the very nature of humans here.
But that is, of course, being naive. I know that.
I can’t wait for the python bindings so I can integrate Gajim (a jabber client in PyGTK that MOVES [as opposed to Gossip :$] see gajim.org) with galago. Have you hosted the pre-release somewhere?
@Nikos: Not yet. Christian wants to move away from his own gobject replacement back to using gobjects first. This will make it much more easy to create Python bindings.
My current attempt only creates partial/unusable python bindings for the gtk-galago stuff.
Hi Guys,
first of all, thx for this piece of software (galago as well kicmproxy). And yes, Philip is right, there is no really war between the two desktop environments.
Right now we (that’s MOTU IM Team, RobTaylor and RobertMcQueen) prepared a spec for integrating your ideas into Ubuntu (wiki.ubuntu.com/MOTUIM/De… and Kubuntu. This we want to be discussed at UBZ (wiki.ubuntu.com/UbuntuBel…
If you want to help us (I saw Nikos comment, which I was really surprised, because I’m a fan of gajim :)) come around #motu-im or #ipcf on freenode and help us to make it happen :)
Regards,
\sh
Hrm, OK, why is everybody railing against poor glib?
host ~ $ ll -h /usr/lib/libglib-2.0.so.0.1600.5
-rwxr-xr-x 1 root root 811K 19. Sep 17:39 /usr/lib/libglib-2.0.so.0.1600.5
host ~ $ ldd /usr/lib/libglib-2.0.so.0.1600.5
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7d3c000)
/lib/ld-linux.so.2 (0x80000000)
host ~ $ ll -h /usr/kde/3.5/lib/libkdecore.so.4.2.0
-rwxr-xr-x 1 root root 2,0M 8. Aug 17:34 /usr/kde/3.5/lib/libkdecore.so.4.2.0
host ~ $ ldd /usr/kde/3.5/lib/libkdecore.so.4.2.0
linux-gate.so.1 => (0xffffe000)
libutempter.so.0 => /usr/lib/libutempter.so.0 (0xb7cf9000)
libDCOP.so.4 => /usr/kde/3.5/lib/libDCOP.so.4 (0xb7cca000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7cb8000)
libutil.so.1 => /lib/libutil.so.1 (0xb7cb4000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb7c9c000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xb7c6b000)
libkdefx.so.4 => /usr/kde/3.5/lib/libkdefx.so.4 (0xb7c40000)
libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0xb756f000)
libmng.so.1 => /usr/lib/libmng.so.1 (0xb7510000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb74f1000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb74e7000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb74e1000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb74d7000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb74d2000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb74cf000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb74bd000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7492000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7414000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb73f4000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb73d0000)
libz.so.1 => /lib/libz.so.1 (0xb73be000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb73b1000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb73a7000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb738f000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7378000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb736f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7286000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7283000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb727d000)
libdl.so.2 => /lib/libdl.so.2 (0xb7279000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6 (0xb719c000)
libm.so.6 => /lib/libm.so.6 (0xb7177000)
libc.so.6 => /lib/libc.so.6 (0xb704e000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 (0xb7044000)
/lib/ld-linux.so.2 (0x80000000)