v0.4

This document contains a few notes about the refactoring planned for v0.4.

This version will no longer require Galry. It will build upon Vispy instead. This will result in a faster and more memory-efficient program.

In addition, the core architecture of the GUI will be improved. The Model-View-Controller (MVC) pattern will be followed so as to improve the modularity and clarity of the code. Eventually, the program should also contain less lines of code.

Global model

The program contains a singleton instance of a Model. This class notably wraps the Experiment object, which provides object-oriented access to an experiment's data.

The Model also defines update methods:

• merge_clusters
• split_clusters
• change_cluster_color
• change_cluster_group
• change_group_name
• change_group_color
• add_group
• delete_group

These methods update the underlying Experiment class, which itself updates the PyTables File object. The modifications are automatically saved when the file is closed.

Views

Each widget of the program is a View. A View is a standalone module that can be used independently of the program. Most views are based on Vispy. An exception is the ClusterView, which is a pure Qt widget.

A View communicates with the outside world through two mechanisms:

• Outgoing information is emitted through Qt signals, which are tied to the View class.
• Ingoing information is transmitted by Python methods of the class. Those can also be called by Qt slots by external objects, but the View does not have to worry about this (it is not one of its concerns).

For example, the ClusterView defines the following signals:

• select_clusters: when clusters are selected.
• change_clusters_color_dialog: when the user requests to change clusters' colors.
• change_clusters_name_dialog: when the user requests to change clusters' names.
• change_groups_color_dialog: when the user requests to change groups' colors.
• change_groups_name_dialog: when the user requests to change groups' names.

and the following methods:

• select_clusters
• change_clusters_color
• change_clusters_name
• change_groups_color
• change_groups_name
• add_group
• delete_groups
• merge_clusters
• split_clusters
• set_quality: to set the quality of the clusters. This requires a special method, because the quality is computed in an external thread or process (intensive CPU-bound computation).

Each Vispy view implements internal models and controllers. The internal model contains read-only arrays provided by the global Model (refer to the same location in memory). The controller updates the view in response to action methods. The GLOO module of Vispy should be carefully exploited here: it allows one to update GPU buffers efficiently.

The internal MVC architecture requires close integration with Vispy, notably the visuals module.

Global controller

The Controller links the Model and the Views. It has the following methods:

• merge_clusters
• split_clusters
• change_clusters_color
• change_clusters_name
• change_groups_color
• change_groups_name
• delete_groups
• add_group
• undo
• redo
• compute_similarity: start computing the similarity matrix in an external thread
• update_similarity: called when the similarity matrix has been computed, and when the relevant views need to be updated appropriately

Each of these methods:

• may call the corresponding method in the model
• may call the corresponding methods in the views
• may add the action to the undo stack
• may call other methods of the Controller (dependent actions)

Further notes

The controller defines Qt actions. Each controller's method is an action's slot. _changed signals to signify the views that the model has changed undo stack: can use QUndoCommand framework