Big Plans Ahead...

1. TinkerCell will come with a folder full of modules, e.g. enzyme kinetics, gene regulation

2. Each reaction arc, such as a gene regulation arc, can be used to represent one of these modules. The interface will allow the user to double click on the gene regulation connector and load one of the modules to represent that process.

3. All modules will be encapsulated by default. Input/outputs will be represented using small input/output indicators on the items inside the module.

4. Users will be able to write Octave code for TinkerCell.

Big change to Core library

Qt has stopped supporting the drawItems(...) method that allowed multiple graphic v, each showing different items from the scene. As a result, I have adopted a different (possibly better) architecture:

A "NetworkHandle" class is used to represent a network.
Each NetworkHandle consists of one or more NetworkWindows, where each NetworkWindow can contain a scene or a text editor. So, a network is defined by using multiple scenes and/or text editors.

Helper functions for Python

Since the new API uses C data structures, the interface is a bit unfriendly for Python. So, I added the following functions for ease of programming:


toItems: converts Python list of Items to ArrayOfItems
fromItems: converts ArrayOfItems to Python list of Items

toStrings: converts Python list of strings to ArrayOfStrings
fromStrings: converts ArrayOfStrings to Python list of strings

toMatrix: converts Python list of list of reals to Matrix (two optional arguments for row and column names)
fromMatrix: converts Matrix to a list of row names, column names, and 2D list of reals

New API

The C API has been remodeled so that it can be wrapped automatically by SWIG.
SWIG will automatically generate wrappers for Python, Perl, R, and Ruby -- so all those languages will be able to contribute plugins.

To use the new API, a programmer must be familiar with the 6 data structures listed below. All languages (C, Python, R, etc) will have the same interface and will use the same data structures. Of course, the syntax will be slightly different: in C, one would write "Matrix M = ..." whereas in Python one would write "M = ..." and in Perl, "$M = ...".

The six main data structures are:

Item: just a reference to a TinkerCell object (memory pointer)

String: exactly what the name means

ArrayOfItems: array of Items

example use:
ArrayOfItems A = newArrayOfItems(4
A.length
nthItem(A,3)
deleteArrayOfItems(&A)

ArrayOfStrings: array of Strings

example use:
ArrayOfStrings S = newArrayOfStrings(4)
S.length
nthString(S,3)
deleteArrayOfStrings(&S)

Matrix: two dimensional array of reals with row and column names. The rownames and colnames fields are ArrayOfString objects

example use:
M = newMatrix(4,3)
M.rows
M.cols
getColumnName(M,2)
setColumnName(M,2,"col2")
getRowName(M,1)
setRowName(M,1,"row1")
getValue(M,2,3)
setValue(M,2,3,0.5)
deleteMatrix(&M)

TableOfStrings: two dimensional array of Strings with row and column names. The rownames and colnames fields are ArrayOfString objects

example use:
TableOfStrings S = newTableOfStrings(4,5)
S.rows
S.cols
nthString( S.rownames, 1)
nthString( S.colnames, 2)
getString(S,2,3)
setString(S,2,3,"hello")
deleteTableOfStrings(&S)

Python plugins easier to add

Before, adding new Python plugins required adding a new line in the pythonscripts.txt file. Each line described the location of the script, its name, description, icon, and when and how it should be displayed. This was not appropriate for a "plugin", because a user cannot simply download a plugin and expect it to work. In addition to downloading, editing the pythonscripts.txt file was also required.

New method is to require each Python script to have header a the top. Here is the header from the hillEquations.py plugin:

"""
category: Generate kinetics
name: Hill equations
description: generate the equilibrium rate equation for transcription
icon: Plugins/c/hillequation.png
menu: yes
specific for: Synthesis
tool: yes
"""

The header is quite self-explanatory (hopefully), except for the "menu" , "specific for", and "tool" attributes. The menu attribute is used to state whether or not this function should be listed in the menu of functions. The "specific for" attribute is used to indicate whether this function specifically applies to items belonging in a particular family. When items of this family are selected, the function will appear in the context menu (right-click). The tool attribute indicates whether or not to show this function on the side along with other tools (alternative interface to context menu).

All Python scripts must be located in one of the following folders, otherwise it will not be loaded.

/TinkerCell/py
/py

And all the scripts must have the suffix "py", otherwise they will be ignored.

Scripts can be uploaded and downloaded from: http://tinkercell.wikidot.com/python-scripts

Sliders

The ODE simulation and SSA simulation provide sliders that can be used to experiment with values and see the change in the simulation results instantly.

How it works:

The Core library provides a new class called MultithreadedSliderWidget, which combines a slider widget with the CThread class to provide a widget that would call functions inside a C library on a separate thread as the slider changes value.

The thread is destroyed when the slider window is closed.

The DynamicCodeTool plugin provides a C function called compileBuildLoadSliders, which is almost the same as compileBuildLoad, except for the fact that it attaches a MulthithreadedSliderWidget to the CThread that would be normally created with the compileBuildLoad call.

Results on the screen

The default plot tool now provides a histogram function, which is used by the runssa.c plugin to draw histograms after a stochastic simulation.


Using the displayNumber() function, the runssa.c and runcvode.c simulation functions display results of the simulation, such as steady states, mean, and variance on the screen itself.

Input functions

An input tab is added along with the other parts tabs. This new input tab contains input functions such as Impulse function, Step function, and Wave function, all of which can be used to set forcing functions on one or more molecules.

The CatalogWidget widget which originally just showed the nodes and connections now contains a new slot called addNewButton that allows other plugins to add new tabs to the Catalog. The SimulationEventTool plugin uses this feature to add the inputs tab. The ModuleTool uses this feature to add the Module tab.

libSBML via Antimony

The following functions (C and Python) are now available for reading and writing SBML:

loadSBMLString load SBML model using the XML string as input.
loadAntimonyString load Antimony model using the model string as input.
loadSBMLFile load SBML model using the file name as input.
loadAntimonyFile load Antimony model using the file name as input.
getSBMLString get SBML as a string from either a subset of items or all items.
getAntimonyString get Antimony model string from either a subset of items or all items.
writeSBMLFile write the SBML to an xml file.
writeAntimonyFile write the Antimony model to a text file.

Changes to module implementation

The Module Tool originally used the merge items option from the Core library in order to merge two connected items. Upon deletion, the command was undone. The problem was during copy/paste, because the original handle was hidden, so it would not get copied. Since this was creating a complicated situation, I opted to change the direction entirely:

Now, the ModuleTool does not merge any items. Instead, it just provides the visual connections and interface. It also provides a very important function:

connectedItems( list of graphics items, list of handles, list of handles )

The above function searches the list of graphics items and fills in the two other lists provided in the argument (so those are outputs). The two lists will contain the set of nodes that are replaced and the set of new nodes that replace the old ones. Other tools use this information when generating the model. So, the responsibility of modular deconstruction has been shifted to the other tools instead of a single tool.

For example, the getRates function in StoichiometryTool does the following:
QList from, to;
ModuleTool::connectedItems(handles, from,to);

for each rate
rates[i].replace(from[i]->fullName(),to[i]->fullName());



A summary of the tool categories and their dependencies ( right side = more dependent)