Part 2: Hacking on xlog

In the first part on "Hacking on xlog" I eluded to the fact that xlog was good, but that I wanted to made some changes to it. The following article discusses these changes. What changes do I want to make to xlog?

• Be able to add additional rules for more contests - Currently xlog has some useful rules and checks (eg. duplicates) but they are either overly general (check for all the duplicates in a log file) or specific to a particular competition. It would be good able to support different contests rules by either an extension language or a plug-in or dynamic library architecture.
• Make the User Interface (UI) layout configurable - It would be good to be able to modify the UI to suit the way that I setup and use my set radio. Gnome and Gtk+ applications can be written using libglade, where the UI is defined in an XML file along with the functions that they call. It is then possible to rearrange the interface via the XML code, without touching any of the underlying code. Currently, xlog has 'hardcoded' all of the widgets and their positions into the code of the application itself.
• Add support for other forms of radio operation - Logging is necessary in on-air contests but there are other types of radio operation where a suitable logging application would also be very useful. Examples include: Running nets, Message Relaying and Emergency Operations.
• Multiple Operator Support - Support for multi-user access and multiple user logs. This would be useful for multiple user stations and for collating logs for competition managers.

In order to make these changes and make any form of useful contribution, I'm going to have to download the code and spend some time poking around in it, just to understand how it works. More about this in my next post.