This is a draft specification for the major architectural changes planned for Virtaal 0.3. The main aim of these changes is to create a stable, robust and easy-to-use platform from which all the future changes can be easily implemented. For this purpose it has been decided to use a MVC architecture.

While this page is in its draft stage all statements made herein should be considered suggestions or opinions. Specific sections, paragraphs or sentences that are not yet decided on will be marked with ”(??)”.

With a basic understanding of the MVC pattern as well as knowledge of Virtaal's features, the diagram should be reasonably self-explanitory. The following description contains notes about unexpected, unclear or new concepts introduced.

The Store group in the diagram represents the model, view and controller that is related to store-level activities. In terms of the GUI, the StoreView would be the main gtk.TreeView widget as it is in Virtaal 0.2. The StoreModel is a basic wrapper for basic translation store which (mainly) handles the loading, saving and parsing of translation files.

Similarly the Unit group represents the unit-level components. The UnitView specifically represents the GUI of the unit editor (the selected unit) as it is in Virtaal 0.2.

The Mode MVC-triplet produces a ModeCursor that specifies which units are usable in the currently selected mode. This cursor will be used by the StoreController and/or UnitController.

The MainWindow object is responsible for managing the creation of the other main components and may also serve as proxy for communications where no “official” channel is available(??).

Adding features to Virtaal will be much easier once this architecture is in place. The way in which this is done can make the difference between a nice, modular system and a convoluted mountain of messy code. Extensions can be done in one of three ways(??):

Extending relevant, existing component(s). This is typically how basic functionality will be implemented.

As separate MVC modules. Using this approach, a feature (or extension) creates its own model(s), view(s) and/or controller. These components then connect to the signals they are interested in, in order to connect themselves to the system. This should be the preferred method for bigger, more complicated features such as translation memory.(??)

As plug-ins. Separate classes (possibly also with a MVC design) that are dynamically loaded and connects to signals of the existing components in order to connect to the system. This approach should be used by smaller, non-critical features.(??)

This is section is only applicable to the virtaal/ source sub-directory, seeing as the rest of the directory structure is serving us quite well.

Related code should definitely be grouped together into modules and sub-modules. Here are some possibilities:

Create sub-directories for models, views and controllers and put the files containing the relevant classes in each of those directories. Example for unit-related class files: models/unitmodel.py, views/unitview.py, controllers/unitcontroller.py

Create a separate (sub-)module for each MVC group of files/classes. This would mean the creation of at least the store, unit and mode sub-directories. Example for unit-related class files: unit/unitmodel.py, unit/unitview.py, unit/unitcontroller.py

(??)

Note that there is no mention of a plug-ins directory, because it has not been decided if plug-ins will be supported.

Seeing as this implementation will affect our planning schedule, the implementation of specific parts of the code should be ordered in such a way that other planned work can be started as soon as possible.

All implementation should reuse as much code as possible from Virtaal 0.2 in order to save development time.

Pressing Enter in a target does not move focus to the next plural textview.

If the first plural form is changed, the change is not visible after switching to a different unit.Problem was much bigger than mentioned. No changes to plurals were saved because of multistring's suckage.

Recent files not updating.

Editing area does not respond to changes in window size.Could not reproduce

Widget heights are not 100% correct for single-row units: too much space at the bottom.

Opening a second file does not work.

Excessive flickering when changing units.

Without specifying your translator e-mail address, each time a file is saved, a contributer heading is added regardless of whether there is one (or more) already. This is probably related to the checks in translate.storage.poheader.poheader.updatecontributor().