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)

SBOL Visual

SBOL Visual in TinkerCell. Although not exactly a replica of the original, it is close. I don't have an SVG import in TinkerCell yet, but all of these are vector graphics (drawn using TinkerCell's drawing program).

gnuplot

Having a high-quality plotting tool is necessary for TinkerCell, so gnuplot seemed like the right choice. gnuplot has a scripting interface and can provide a large variety of graphs. The GnuplotTool plugin generates script files and pipes them into the gnuplot executable. So, the only work that is done is generating the scripts. The plugin also provides a scripting window where users can plot more advanced plots (anything allowed by gnuplot).

GnuplotTool and the default (old) Plot Tool provide the same functionality. When one has been loaded, the other cannot load. So, the one that loads first wins (this depends on which plugin was created first). Disabling one of these plugins from the settings menu would be ideal way to choose one of them.

The right picture above is from TinkerCell. The left picture shows some demo plots using gnuplot (not done in TinkerCell...yet).

Small change to ConsoleWindow class

Some changes in the Core library:

The ConsoleWindow was a static item, allowing calls such as:

ConsoleWindow::message("hello");

ConsoleWindow::error("parse error");

ConsoleWindow is no longer static. It belongs with MainWindow. So, the above calls are replaced with:

if (console())

{

console()->message("hello");

console()->error("parse error");

}

The console() function exists in MainWindow, Tool, GraphicsScene, NetworkWindow, and TextEditor. All of these functions call MainWindow's console() function, so they return the same pointer. However, if there are two MainWindow instances, then each will contain a different console....in case that some day there is some need to create two main windows.

Additionally, a new function, "eval", has been added, which current can be used to evaluate a Python expression because the Python plugin controls the console at the present.

console()->eval("print 1+2");