Wed Feb 11 09:26:55 GMT 2004

Incoherent program-philosophy time: Looking at Kopete which has its earliest CVS log at 2003/10/25; and the following description: 

Kopete is a flexible and extendable multiple protocol instant
messaging system designed as a plugin-based system.

Another well-known open source IM client is Gaim; first CVS log at 2002/11/14; has the following description: 

Gaim is a multi-protocol instant messaging client...

Doubtless the kopete people would disagree with me here, but I'd say that their project was utterly redundant. What advantages does kopete bring that could not have been submitted to gaim itself? Why go to the time and effort to independently develop two programs which do virtually the same thing?

Now there are other, significant differences. Gaim uses the GTK+ toolkit. Kopete uses Qt. Gaim is primarily C, Kopete is C++. In fact Kopete is fairly tightly bounded to KDE, whereas I think Gaim is not so quite involved with Gnome.

So we can reduce this redundancy problem to the problem of two desktops, if it is a problem. I'm not sure it is, after all competition is good and drives development. Is it that much of a problem that some coders have spent time and effort re-inventing the wheel anyway?

Well I think it is a problem, unless you are heavily camped in either desktop. I'm not. When I develop a GUI application, I have to make a decision about which environment suits me best. I know there's more to it than that - Gnome has all that other stuff like Glib and KDE isn't just QT - but the GUI is a major consideration.

So if I opt for (say) GTK+, will some QT zealot prefer to code an alternative to using my version?

I run a mixture of Gnome and KDE applications. I use Konqueror as a web browser, Gimp for some graphic stuff, etc. The two toolkits are somewhat annoying because they do not interact particularly well.

When I write a GUI app, I want the interface code to be as separate from the logic as possible, to make swapping them in and out as easy as possible. Don't code an alternative, write a new interface for me!

Glade is a GTK+ interface builder. You use a drag-and-drop program to compose a UI, and it can generate the corresponding GTK+ code. You can save the project seperately as an XML application.

What is really exciting however is the companion libglade. This library reads in the XML that Glade writes at runtime and constructs the UI from that.

You therefore don't even need to necessarily use the UI builder to generate the XML if you don't want to. Perhaps you'll just translate a UI described in a different XML application.

So why do I think this is exciting?

  1. Alter/tweak the UI at runtime, without a recompilation.
  2. Are you a user of a program with an XML UI? remove annoying portions of it locally, no intimate understanding of the program code needed
  3. Translate (via XSL) an interface description in a different XML application. I haven't looked at the design of the XML glade dialect much myself, it might be a nightmare; but at least that nightmare could be hidden behind a translation.
  4. Want a KDE version? Write a runtime, XML-interpreting UI builder for KDE!

Argh! so this rant has gone off-track a little bit. What else have I got to cover?

  • Advantages of external program organisation (say, the GObject way) vs. internal (C++ classes)
  • Kopete, as an application, is REALLY annoying me