Virtaal's MVCisation

Over the last two weeks Virtaal's code has been refactored to be more easily extendible. Changing Virtaal to a MVC architecture proved to be quite an intense and interesting endeavor (my GTalk status was "Deep hack mode" for most of these two weeks), but well worth it. And here we are! Virtaal's MVC branch is just about on par with the trunk version.

It was a week like any other in mid-November of 2008 and at the Translate.org.za offices was this code monkey, Walter, tasked with putting the "replace" in "search and replace" for the young and beloved program known as Virtaal. 'Twas not an easy quest and cost Walter a great amount of discomfort; from frustration-induced hair-loss to violent fluctuations in digestive processes: Changing the value of translation units was easy enough, but having the GUI display such an update proved nearly impossible without ogreish hacks (ogreish in both beauty and size) that would make this expectedly simple feature a maintenance nightmare. Being aware of the future plans for this virtual youngster (spoiler: the plans end with world domination... muhaha!), he decided to, instead of pushing the limits of his psyche, plead with his overseers to invest in its metamorphosis into a magnificent MVC-butterfly. So started the "Great MVCisation of Virtaal", as it will henceforth be known.

The above-mentioned pleading included a very detailed discussion about exactly how this refactoring process would be implemented, what the pro's and cons are and how long it will take. We even went as far as describing the basic class layout! There wasn't really all that much begging and convincing, since we all knew that this was a necessary step in getting Virtaal ready for the huge changes and additions that lay ahead. We needed to get it modular enough so that any new functionality can be kept separate (or at least as separate as possible) and use the core functionality much as if it was a service. The MVC architectural pattern was the best way we could think of to do this. To let you (the community) know about my intentions and methods, the "Virtaal MVC" wiki-page was created (I see it's still marked as a draft... I'll have to update that).

Now, before I go any further, I would like to, in reference to this interesting blog by Malcolm Tredinnick, state that I am aware that "MVC", as defined in Virtaal's context, is not the same as the original MVC definition. I have, at certain places in the code, knowingly and willfully broken away from the original definition of MVC in order to keep the code clean and clear. Still, I'm sure I've offended the MVC-deities in other ways too. It might not be 100% MVC-compliant, but it's close enough and a great improvement over the old structure. Either way, if you haven't done so already and have any interest in the MVC architectural pattern, I would like to strongly recommend reading Malcolm's post linked above.

Being only a refactoring process I didn't hold back at all when it came to copying code into the new structure. In fact, there are quite a few classes that was renamed and only changed enough to work within the new environment. Indeed, it would be very foolish to try and replace the hard-core (Gtk+ and other) hacking that went into those classes!

One of the design-decisions we made was for inter-object communications to stick to GObject events. Although it isn't used as extensively and religiously as might be expected, the defined signals have been intentionally been kept to a minimum: first make sure our classes are as lean as possible and add signals as they become necessary. That way we effectively avoid having unused signals floating around. We have also given controllers, specifically, a lot of freedom in terms of how far they are allowed access other objects directly. It works well that way and can easily be modified if it ever should present a problem.

As mentioned earler the MVCised branch is mostly on par with the trunk version. It might also has a bug or two that trunk doesn't, but also a few feature improvements. Once we are satisfied that, functionality-wise, the refactored Virtaal is in no way worse (or not sufficiently worse ;)) than the current trunk version, it will be moved to trunk. Please feel free to take a look at (or test) the code and let me know if you have any comments, complaints, rants, or whatever. :)

In the near future we (Alaa and I) will start expanding the functionality with translation memory and then go on with the infinitely long lists of things to come. I sincerely hope we get to the coffee-making functionality soon! :P

P.S. Python is still awesome!