29 Apr 2011 AlanHorkan   » (Master)

Developing MComix. Part 1: A rose by any other name...

Comix is a comic and image viewer program written using Python and GTK. I was interested in making a few changes to the project. I am getting back into programming, learning a more about PyGTK and hopefully making some improvements the program will fit better on a small screen netbook. Unfortunately Comix is unmaintained, the developer of the project seems to be unavailable and has not made any updates since 2009. (You can discover this for yourself by checking the Comix website particularly by checking the Sourceforge page for Comix and taking a look at the last date on the Changelog, and various reports in the bug tracker. It may still be possible to get in contact with him but the project is not active.)

I was pleased to discover MComix a fork of Comix, continuing on from Comix version 4.0.4. It isn't clear what the M in MComix stands for but from the picture in the about dialog I think "Monkey Comix" is a fairly safe guess.
(Later I also discovered another fork of Comix by HellHover which incorporates many of the patches submitted to Comix. It is more like a spork than a fork, as it keeps close to the original.)

The attitude and prompt reponse from the MComix developers was encouraging so I got to work putting together a few changes and sending in a patch (after a discussion clarifying that MComix is licensed under the GNU GPL version 2).
Freedom to change the source code and even fork the project is a great power to have but it comes with responsibility. Getting others to help is not easy, you want people to submit code, help with translations, or get a project packaged nicely for different operating systems, and generally help with the work of maintaining a project, so even though forking is possible it is not something you want to do unless absolutely necessary. Knowing it would take some time and effort to make changes it is a great relief to know there is a good chance others will accept the change help maintain it. Putting a lot of work into a patch and having it go to waste, is a big disappointment and severly discourages anyone from contributing to a project.

The patches took less time to write and test than the email explaining the rationale for the changes. Developers often like to do things their own way, and a without a proper explanation, patches might not be accepted. As a fork of Comix I was optimistic the developers would be more accepting of change but I wasn't going to take any chances.

The first - and to my mind most important - change was relatively simple but something I would strongly recommend to any program, especially a fork: separate out the name of the program. I set a constant and called it "APPNAME" and replaced the word MComix, so that if the name ever needs to be changed again or even changed back to Comix it can be done with only a few small changes.
The long and winding history of Mosiac, Netscape, Mozilla, m/b, Phoenix, Firebird, Firefox, Iceweasel, is a particularly extreme example of the many name changes a project can go through. If someone doesn't like the name the can easily change it without needing to fork the project. Making it a little bit easier for others to customize and fork the code gives them one less reason why they would need to, and they can continue to pool their efforts on the things they do agree on.

The patch also contained changes to help with internationalisation (i18n) and localisation (l10n).
There was also a small change to the command line arguments.

When the patch was accepted I was very satisfied and confident the developers were the kind of people I would enjoy working with further. Answers to a few other questions in my email confirmed our interests were different but mutually beneficial. Straight away I was thinking about the next changes I might make.

Syndicated 2011-04-23 23:49:11 from Alan Horkan

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!