Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Bugfixing and Feature Enhancements for Glom
As part of my Become a C++ Developer in Six Month! quest I started to delve into a considerably large C++ project which has been around for eight years: Glom, a database designer and a database user interface. So far I have reported a few bugs (even fixed one myself) and finished my work on a feature enhancement. With finished I mean 90%-finished, as I could not find out how to fix an annoying detail and also forgot some documentation updates (note to myself: next time you blame a project for poor documentation remind yourself how easy it is to forget updating out-of-code documenation).
OK, so how can I make my next feature enhancement a total success?
First, let's see how a feature enhancement compares to a bug fix. I guess it is fair to say that a bug fix only requires local understanding of the code. Now a feature enhancement is probably code that doesn't exist yet, so you can't simply start a debug session to find the proper context. It may even require a mini-design phase initially!
(And I think I made a mistake right there, by not writing down the questions I came up with. Perhaps I thought my questions would be too stupid and stem from my - naturally! - very limited understanding of Glom. But such a list may help others to understand why you got stuck at later points!)
Our mini-design phase will help us to analyse what needs to be done, and in which order. For the feature enhancement at hand - introducing a further navigation option for a Layout Dialog in Glom - we have identified these steps:
- Show the new option in the appropiate Layout Dialog ("Related Record Layout").
- Identify the class which represents the data for the dialog.
- Modify this class' API to handle the new option.
- (Re-)Connect the dialog's signal handlers to the (modified) API.
- Delegate user modifications to the persistance layer (here: a Glom XML file), and make sure we can restore the modifications on the next run!
- Detect the code that controls the navigation between related records and change appropiately.
Step 2 and 6 might be quite difficult. Perhaps it is easier to simply ask the project's developers for help!
Once I started making changes I realized some would potentially break stuff. Lacking automated testing I found I had to compare the debug runs of before-changes and after-changes (just have 2 parallel debug sessions if possible). This costs a lot of time but I think it is a necessary evil.
Finally I had a patch ready, but things don't stop there! Part of the feedback made me rewrite most of it (happens, nothing bad about it). Again, it helps to form a list of necessary steps, as it makes it harder to forget about the details (d'oh!).
So what did we learn? Trivial feature enhancements are a lie ;-)
