Comments on: Galago and other important desktop integration compontents

By: Tom

Tom — Fri, 12 Dec 2008 17:19:47 +0000

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 (0×80000000)
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 (0×80000000)

By: shermann

shermann — Tue, 27 Sep 2005 01:44:12 +0000

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

By: Philip Van Hoof

Philip Van Hoof — Mon, 11 Jul 2005 15:52:25 +0000

@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.

By: Nikos Kouremenos

Nikos Kouremenos — Sat, 25 Jun 2005 13:22:04 +0000

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?

By: Philip Van Hoof

Philip Van Hoof — Tue, 21 Jun 2005 22:03:43 +0000

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.

By: Philip Van Hoof

Philip Van Hoof — Tue, 21 Jun 2005 22:01:45 +0000

"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.

By: Allen Hourre

Allen Hourre — Tue, 21 Jun 2005 13:43:55 +0000

> 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 :-)

By: Philip Van Hoof

Philip Van Hoof — Mon, 20 Jun 2005 23:45:43 +0000

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.

By: Allen Hourre

Allen Hourre — Mon, 20 Jun 2005 18:44:57 +0000

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.

By: Joel Dimbernat

Joel Dimbernat — Mon, 20 Jun 2005 12:02:13 +0000

Can’t wait for your integration of galago in gossip and the python bindings, I was waiting for both of them.