3D plotter and 2-way steady state analysis

The PlotTool now contains Plot2DWidget and Plot3DWidget, which are used for plotting 2D and 3D graphs. The "runsteadystate" C program now provides 2-parameter steady state analysis. See diagram below.

Some changes worth noting...

The class OutputWindow has been changed to ConsoleWindow, which makes more sense.

ItemHandle can be "hidden" from the SymbolsTable by setting visible=false. The SymbolsTable stores all the objects in the network, so this is a way of using a handle without making it part of the network itself. 

TextParser class

The TextParser class is the parent class for all parser tools, such as the Antimony parser tool. This class listens to events in the text editor and responds accordingly. This parent class simply provides a basic structure for other parser tools.

activate ()
set this parser as the current parser

deactivate ()
this parser is no longer the current parser

parse (TextEditor *)
this parser has been requested to parse the text inside the given text editor

textChanged (TextEditor *, const QString &, const QString &, const QString &)
some text inside this editor has been changed

lineChanged (TextEditor *, int, const QString &)
the cursor has moved to a different line

validSyntax (bool)
signal indicating invalid syntax

setParser (TextParser *)
set the text parser for all text editors. The current text parser can be obtained using

currentParser();
The current text parser that is being used (can be 0 if none).

Antimony Parser

new class: CodeEditor (Core library)

Core Editor is designed to be the base class for any coding/scripting widget. It is borrowed from Qt's example set.

new plug-in: AntimonyTool

The AntimonyTool uses libAntimony to parse the text in the current TextEditor and calls setItems(...) in the current TextEditor upon

parsing.

Result: parse with antimony and get all the other features of TinkerCell that work at the handles level. This would include all the C and Python functions.

Drawback: this parser is dependent on the other plug-ins, e.g. the StoichiometryTool and BasicInformationTool. The parser assumes the existence of data tables named "Rates", "Numerical Attributes", and "Stoichiometry".

Users can build models using text or graphics, side by side.

Significant changes to Core library : the TextEditor

Here was the idea that forced a remodelling of the Core library:

What if TinkerCell could support two method of model construction: graphical (drawing) and text-based (scripting)

The resulting design is summarized by the picture to the right. Here are the major modifications:

1. A new class, NetworkWindow, has been created. This class is an MDI widget that is used to create the subwindows in the main window.  The NetworkWindow contains two important members: history stack and symbols table
2. Each NetworkWindow can contain either a GraphicsScene or a TextEditor (new class). 
3. The GraphicsScene and the TextEditor use their parent NetworkWindow's history stack and symbols table. 
4. Just as GraphicsScene uses graphics items, TextEditor uses TextItem
5. The MainWindow has three signals for indicating that items are inserted or removed. One is the old itemsInserted and itemsRemoved which is connected to GraphicsScene. The second is the same but for TextEditor. The third is generic to GraphicsScene or TextEditor: this signal just contains the handles that have been inserted. Therefore, plug-ins that only need to worry about the handles can listen to this last signal. These plug-ins would work whether the user is using text mode or graphics mode.

The TextEditor is a very simple class (contrary to GraphicsScene). TextEditor does NOT parse the text. The parsing MUST be done by a plug-in. The parser plug-in is expected to listen to the signals in TextEditor and respond by calling the insertItem and removeItem methods in TextEditor. 

TextEditor also uses a special undo command that is a composite command. This composite command changes the text along with the other change that it is meant to do (e.g. data changed). The push() method in TextEditor automatically creates this new composite command from the given command. 

Plug-ins modified:

Tools such as StoichiometryTool and other data-related tool not listen to the generic itemsInserted and itemsRemoved signals. This means that the tools would also work the same when user is using TextEditor or GraphicsScene -- convenient!

A Note about casting in TinkerCell

The qgraphicsitem_cast is used to cast at the "top level" graphical items, i.e. PartGraphicsItem, ConnectionGraphicsItem, TextGraphicsItem, PartGraphicsItem::ControlPoint, ConnectionGraphicsItem::ControlPoint, and GraphicalTool. Note, ControlPoint::getControlPoint() can be used to get either one of the ControlPoint classes.

For example:

PartGraphicsItem * part =  qgraphicsitem_cast(item)

ConnectionGraphicsItem * connection = qgraphicsitem_cast(item)

However, this type casting is NOT used for subclasses, such as ArrowHeadItem or ModuleLinkerItem, both of which inherit from PartGraphicsItem. Casting for these subclasses is done using the class_name static field.

For example:

PartGraphicsItem * part =  qgraphicsitem_cast(item)

if (part->className == ArrowHeadItem::class_name)

{

      ArroHeadItem * arrow = static_cast(part); 
}

Reason for this way of casting:

The top level classes are used by various tools, so the qgraphicsitem_cast is reseved for tools to identify which of the top level class an item belong to. The subclasses are usually only relevant for one or two tools, e.g. the ModuleLinkerItem. Other tools do not need to differentiate between PartGraphicsItem and ModuleLinkerItem. 

BioBricks in TinkerCell

A first attempt at storing a composite BioBrick

The BBa_I0462 is composed of 4 other sub-parts. Each part, including the composite part, has author, date, and other annotations. The sequence, however, is a property of each of the sub-parts, not the composite parts.

All this information is stored in this model object drawn in TinkerCell. Here is the Python code for accessing all the information (they can also be viewed through the visual interface).

>>part = tc_find("BBa_I0462")

>>print fromStrings( tc_annotation(part) )

('Caitlin Conboy and Jennifer Braff', '12/04/2003', 'luxR Protein Generator', 'uri', 'reference')

>>print tc_getTextAttribute(part,"format")

BBa

>>print tc_getTextAttribute(part,"type")

composite

>>subparts = fromItems( tc_getChildren(part) )

>>for i in subparts: print tc_getName(i) + " is a " + tc_getFamily(i);

BBa_I0462_B0012 is a Terminator

BBa_I0462_B0010 is a Terminator

BBa_I0462_C0062 is a Coding

BBa_I0462_B0034 is a RBS

>>for i in subparts: print tc_getName(i) + " : "; print fromStrings( tc_annotation(i) );

BBa_I0462_B0012 :

('Reshma Shetty', 'NA', 'Transcription terminator for the E.coli RNA polymerase.', 'uri', 'reference')

BBa_I0462_B0010 :

('Randy Rettberg', '11/19/2003', 'Transcriptional terminator consisting of a 64 bp stem-loop', 'uri', 'reference')

BBa_I0462_C0062 :

('Vinay S Mahajan, Voichita D. Marinescu, Brian Chow, Alexander D Wissner-Gross and Peter Carr', '2003', 'luxR repressor/activator', 'uri', 'reference')

BBa_I0462_B0034 :

('Vinay S Mahajan, Voichita D. Marinescu, Brian Chow, Alexander D Wissner-Gross and Peter Carr', '2003', 'RBS based on Elowitz repressilator', 'uri', 'reference')

>>for i in subparts: print getName(i) + " : "; print getTextAttribute(i,"sequence");

BBa_I0462_B0012 :

tcacactggctcaccttcgggtgggcctttctgcgtttata

BBa_I0462_B0010 :

ccaggcatcaaataaaacgaaaggctcagtcgaaagactgggcctttcgttttatctgttgtttgtcggtgaacgctctc

BBa_I0462_C0062 :

aaagaggag ... ttctgcgtttata

BBa_I0462_B0034 :

aaagaggagaaa

>>print getParameter(subparts[3],"strength")

5.0

Improved way to convert Python and C into buttons and more

"menu.txt" has been replaced with "clibraries.txt" and "pythonscripts.txt", because the fashion in which C libraries and Python scripts were loaded into TinkerCell has been reconstructed. Both of the new files contain much more flexibility about where and how the C and Python programs run. The screenshot on the right shows Python scripts in the context menu and the tools.

Here is how it works now:

The DynamicLibraryMenu class provides the following functions:

addFunction : adds a function to the functions tree.

arguments: function category, name, and icon

addMenuItem : adds a function to the function menu at the top (play button).

arguments: function name and icon

addContextMenuItem : adds a function to the context menu (mouse right button) when items of a particular family are selected; optionally shows the graphical tool.

arguments: target family, function name and icon, and whether or not to show the graphical tool

Therefore, this class simply serves to add actions and buttons to the functions tree, tool bar, and context menu. The actual actions themselves are determined by two other classes:

The LoadCLibrary class performs the following tasks:

1. read and parse clibraries.txt
2. setup the signals and slots that call each function specified in clibraries.txt
3. place actions and toolbuttons using DynamicLibraryMenu

This class can be summarized by the following logic:

text file ---> actions group

action triggered ---> get name ---> get library name ---> new LibraryThread

The PythonTool class performs the following tasks:

1. read and parse pythonscripts.txt
2. host the Python interpreter thread
3. setup the signals and slots that call each script specified in pythonscripts.txt
4. place actions and toolbuttons using DynamicLibraryMenu

This class can be summarized by the following logic:

text file ---> actions group

action triggered ---> get name ---> get file name ---> call runPy

Rationale for the new setup:

1. More modular: if a new interpreter needs to be hosted, say Ruby, then it can use the same format at the PythonTool class.
   
2. More GUI: a C and Python program can appear in up to four places, i.e. the functions tree, the main toolbar menu, context menu, graphical tools

Data get/set C and Python routines

One of the chief design features in TinkerCell is the ability to store tables associated with items or the model. For example, a typical reaction would have a Numerical Data Table called "Stoichiometry" and a Text Data Table called "Rates". Most items have a Numerical Data Table called "Numerical Attributes", i.e. parameters. 

Now, there are certain plug-ins, e.g. the flux balance analysis plug-in, that store data in the model, not pertaining to any particular item. These data are stored in the scene->symbolsTable.modelItem item. 

Plug-ins may provide easier C and Python functions to access these tables, e.g. functions like stoichiometry(), setRates(), getRates(), etc.

But, the Core library provides generic Python and C functions to access any of these data:

use getNumericalDataNames(item) and getTextDataNames(item) to get the list of all table names for that item. Use a null argument to get the tables for the model item.

similarly, there is setNumericalData(item,tablename,rowname,colname,value), getNumericalDataMatrix(item,tablename), and a few other functions.

Improved Plot Window

The plot window can show multiple plots, as shown above. 

The plot window provides an input box for users to write any set of functions and plot those functions. This feature should be useful when designing rate expressions or other functions in the model, i.e. the user can copy the rate expressions here and plot them to see what they look like.

The options on the right-hand side of the input box allow users to specify the variable on the x-axis and other details of the equations they want to plot.