Abstract nonsense

Months ago, I began working on a framework for addressbooks in ekiga.

My tools were the following : C and GObject. I wrote a big pile of code (as an external test program — it’s easier to work with), which did exactly what I wanted. The problem was that the ratio between serious code and stupid code was about 1/100. The GObject framework is nice — but it’s just awful to write. Damien soon confirmed that my 10 000 lines of code would be unmaintainable.

So I changed my tools to : C++ and sigc++. I wrote a much smaller pile of code (as an external test program — it’s easier to work with), which didn’t do exactly what I wanted, but good enough. And in less than 1000 lines of code. Quite readable (it’s C++ after all… don’t hit me Dodji), maintainable.

If I were to start anew now, I would certainly give vala a try — at worse it wouldn’t do the trick. A question fills my mind anytime I think about it : could it be used to rewrite parts of gtk+ more tersely?

PS: for those who don’t get the title of this post, this wikipedia article may help.

Some years ago, we decided that gnomemeeting, being mostly based on pwlib, openh323 and gtk+, which were portable to win32, could perhaps be ported to this platform.

Of course, being a full fledged gnome application, it also used things like gconf, bonobo, etc. Those were a problem.

A –disable-gnome switch and a few #ifdef quite quickly got away with everything but gconf. Last hurdle. Last but not least, as the saying goes.

So I studied a little how gconf was used in gnomemeeting. I wrote a nice gmconf.h header with a pure glib api. Then implemented a gmconf-gconf.c implementation. Easy.

Next step was to go through each and every gconf call in ekiga and replace it by a gmconf call. Oh, the joy. Hundreds of them.

The final step, of course, was to write gmconf-glib.c : a pure glib implementation. This wasn’t particularly difficult. What was a little trickier was that I decided to make it easier to maintain the default settings by parsing the gconf schema. This involved parsing said schema, using GMarkup. It worked!

Of course, when I wrote all of this, my idea was that within one year, all of gnome would be ported to win32 following ekiga’s trail. In fact, ekiga wasn’t ported before much longer (and I don’t even know if gconf made it through), but it still uses gmconf — with some bugfixes here and there but mostly intact.

Yesterday I had to write a piece of code to parse another xml-like chunk of data, but this time used libxml2. Wow. I should have used libxml2 back then : a pleasure. And it sports different api to parse — one is callback-based like GMarkup (hence as painful — but it has its uses), and the other is tree-walk based (much better for the task). Still, I won’t rewrite another gmconf implementation : either we stick with those we have — or we get gconf everywhere.