Abstract nonsense

A few years ago, we wanted to make it as easy as possible to port then-gnomemeeting to win32, and of course, since we had no access to a win32 box, that mostly meant we would make as much of the code portable as we could, by relying on as few dependancies as possible, which meant : glib/gtk+ for the frontend and pwlib/openh323 for the backend.

For that reason, one of us (Damien?) made bonobo optional with careful #ifdef magic ; I took the gnome-druid source and made it pure gtk+ (so gnomemeeting with gnome used normal gnome druid, and gnomeeting without gnome used those butchered sources) ; this took care of most of the ‘offenders’.

Unfortunately, there was still one big hurdle, in the form of numerous and scattered lines of code : we used gconf! So I did the obvious thing : I wrote a nice gmconf api to act as a proxy for gconf, with a mostly trivial gconf implementation, and a mostly trivial glib implementation, and replaced the thousands of call to gconf by calls to gmconf (boring to say the least).

Once there, I could store, modify and react to changes during runtime, but couldn’t store them across runs. This problem is closely related to the issue of default settings. That was also something gconf was doing for us, which had to be handled separately. Creating another default settings file besides the existing .schema didn’t look like a bright idea : that would have meant keeping them in sync, by hand!

This is where GMarkup comes into the picture : it’s a nice and easy way to handle simplified XML, readily available in glib. And what is a gconf .schema file? A simplified XML file! So I dived into GMarkup’s documentation and examples, and quickly had an honestly working piece of code.

This code is still used in ekiga today : when compiled either without gnome support on GNU/* or *BSD or on win32, parsing settings (system or user) is still GMarkup’s task. I’m not sure that will last very long : it’s much easier to port to win32 those days, with already-ported and already-packaged base libs, so perhaps having a non-gnome version loses interest — especially since the gmconf-glib implementation is a piece of code which only us ekiga developpers maintain (although most bugs must have been ironed out since…).