| home | user guide | examples | reference | changelog | resources |
wrapper for a CcmbColor as it is being modified
An interface object between Catacomb and the JPython interpreter. It can pass commands to the interpreter from Catacomb objects and load Python modules. Each loaded module is wrapped in a _CMLINK(env, JythonWrapper, JythonWrapper) object and put in the _TT(modules) list.
layout of components grouped together in a single ColorPanel for making applets Applet configuration. Each AppletConfig object contains the layout for one applet, indicating which views of a model should be included, how they are to be set out within the applet, and what the preferred dimensions are for each.
The appletizer lets you combine a group of windows in a single ColorPanel which can then be saved and reloaded as an applet from a Web site. There is a short cut to the applet tool under the _TT(misc) menu. The process works by defining one or more _CMLINK(env, AppletConfig, AppletConfig) objects which contain a specification of the desired applet: what ColorPanels to include, how to arrange them, and any documentation to go with them. For laying out an applet, the required information is its size and the location of components within it. The only layout allowed for applets is the native java CcmbBorderLayout which has ColorPanels at the top and bottom spanning the full width and at the left, right and center of the middle section. ColorPanels can be empty, and successive border layouts can be nested to an arbitrary depth. On opening the appletizer, you have a display of the applet layout in the center and on the right a row of boxes corresponding to the windows which are currently open. At the top right is a tear-off panel divider (CcmbBorderLayout) which can be dragged onto any ColorPanel of the current layout. Use the clear button to revert to the original. An applet is constructed by dragging in ColorPanel dividers as required and then dropping the boxes you want into the areas where you want them. Although the sizes of sub-panels can be changed by dragging their control points this does not affect the layout of the applet. Instead the sizes of ColorPanels in the final applet are taken from the current sizes of windows on the screen. Each time the applet is previewed the current sizes of the various windows are used. The final applet can be adjusted by previewing it, noting the layout, closing the preview ColorPanel and adjusting the individual windows. Although it tries to use the current sizes of the windows, in fitting them into a rectangular grid it tends to stretch rather than squash to meet the space requirements of the largest ones in either direction. This means that the final applet tends to be rather larger than the windows it is made from, so the windows should generally be squashed below their ideal size when making the applet. The relative positions in the layout also control exactly which windows get stretched most. You may have to try several different arrangements to get it to look right. To add documentation for the applet click the _TT(edit text) button. You can either type into that window, or create a file with a normal editor and load then it into the applet. This text is saved inside the model file when the applet is written and is put into html pages from which the applet can be loaded. To save an applet use the _TT(save model) button and specify a normal Catacomb file name (ie one ending in _T(.ccm)). The model is saved in the usual way, including the applet definition. The model can then be loaded into the Catacomb applet viewer to run the applet. The _TT(save with html) option saves the model as above and also writes template html pages illustrating how to load the applet from html documents on a web server. The html pages are for convenience only and can be regenerated whenever necessary from the model file containing the applet definition. When prompted for a file name, give the desired name for the model, with the _TT(.ccm) extension. The html files will be made from the same root with different extensions.
This is usually the window you will first see on starting Catacomb. It contains menus for loading and saving files, accessing the models the current version has pre-loaded, making new instances of top level objects and a few other functions. The display shows the current object hierarchy. Clicking on a box brings up a window to examine that part of the model, and possibly other windows to display the results of any calculations it defines. The top row menus are the same for all windows. Under _TT(util) are a few utilities that are mainly shortcuts to convenient operations. In particular, the first one, _TT(model browser) lets you retrieve this window from any Catacomb window in case you lose it. The _TT( ? ) button opens the help browser, with any available information about the current window or its contents, and the _TT(X) button shuts the window in case the normal window manager operation doesn't work. The second row of menus is specific to the object browser. The _TT(file) menu contains four different saving options: _TT(save) just saves the structure and parameters of the current model. The _TT(objects) menu contains a list of all the top-level objects currently available. Selecting one of them makes a new instance of that object which appears in the model browser. The display shows the structure of the current model with a colored box for each object and possibly each field. There is always a _CMLINK(core, Sys, Sys) object present, which contains a variety of standard components which may be used with any mode. To change the detail of the display, click the right button on a box to bring up a menu. The _TT(hide) option prevents any of the descendents of an object being shown. _TT(show children) shows lists, pointers and objects, and _TT(show fields) shows all the public fields of an object. You can pan and zoom the display but unlike other displays, it acts like a fish-eye lens: things bunch up at the edges but never actually get lost. All the boxes are color-coded according to type: objects are orange, fields are grey, and lists are green. There are also blue, pink and purple for objects defining calculations, pointers which select elements of a list defined elsewhere, and arbitrary pointers. See the main _CMLINK(., index, contents) page for details of Catacomb's data structure.
occasionally useful messages about what is going on
A wrapper object for JPython modules. It contains a _CMLINK(standard, CalcResults, results display) object which is accessible to the module it wraps and can be used for output from that module. As a normal Catacomb object the wrapper can also be set to receive events from else where in the system and rerun the Python module as necessary. If the module declares a _TT(callable) variable which can be converted to an array of strings then these are assumed to be functions defined in the module, and the interface provides buttons for calling them.
They may occasionally pop up, and are probably worth a read. But, they are not insistent: they do not block other activity until you click OK.
the top of the object hierarchy, containing an overview of the current model Catacomb models are built from a set of objects each intended to encapsulate a different part of the structure of the model. There are also a number of other objects not related to a particular model which control such things as the on-line help system, error messages, and preferences as to how the user interface should operate. The objects belonging to a particular model are arranged hierarchically, as displayed in the _CMLINK(env, CcmbViewEditor, model browser). The framework of the hierarchy is defined by the problem domain, and hard-coded in the objects themselves. But frequently there is a lot of freedom in what to fit within this framework. Catacomb provides a graphical interface for constructing models within these predefined frameworks, and implements numerical methods for computing their behavior. Besides the elementary data types: booleans, ints, doubles, and strings, catacomb uses four complex data types: CcmbObjects, CcmbLists, CcmbSelections and CcmbReferences. _TT(CcmbObjects) can contain any combination of the elementary and complex data types. Catacomb itself is a CcmbObject. The user interface provides tools for making new CcmbObject, setting their fields, documenting them, running any calculations they may define, and saving and restoring from files. _TT(CcmbLists) contain a variable number of CcmbObject all of the same class. The interface provides tools for adding, removing and copying elements. _TT(CcmbSelections) come in various flavors, but always point to a particular vector defined elsewhere in the model. How they operate in a particular case is predefined according to what is needed in the model. They may select just one element of the vector for use locally or a subset, and may have boolean values (the element is either included or it is not) or continuous ones (a variable quantity of each element). For example, in defining a solution, there might be a vector somewhere defining all available solutes and then each solution would have its own vectorPointer selecting certain quantities of each of a subset of these solutes. _TT(CcmbReferences) can point to any component of a model, not just CcmbObjects, but elementary data values too and the other complex types. They have no subtle properties, but each occurrence is restricted to a particular class of target. The interface provides a drag-and-drop mechanism for setting their targets and they refuse anything which is not meaningful in the current context. The second main function of catacomb, after allowing the construction of models within one if its available frameworks, is to compute their behavior and keep it up-to-date whenever any component is changed. Each complete framework contains one or more CcmbObjects which contain calculation methods. They are able to extract the data from the rest of the model and compute its behavior. Whenever the interface is used to examine one of these models, it provides windows to display the results of the calculations, and possibly other displays depending on the nature of the data. The available frameworks are: KSCell, ReactionKinetics, ReactionDiffusion, cfNet, IaFNet, PassiveProp, CellGeometry, ArtCell
They may occasionally pop up, and are probably worth a read. But, they are not insistent: they do not block other activity until you click OK.
Every object in Catacomb has its own CcmbColor and name that distinguish it from other objects of the same type. Colors are also used in CcmbColor tables for displaying image data. The CcmbColor target editor is used for setting a single CcmbColor for an object, a line in a graph, or as part of a CcmbColor table. The CcmbColor chooser uses the RGB system. In the lower window is a set of color axes: red is vertical, green to the lower left and blue to the lower right. There is a complete cube drawn in these axes, of which the forward vertex represents the current color. Any of the circles may be used to change the color. Those on the axes move only along that axis; those on the planes move in two dimensions, and the free axis moves in any direction. Random colors can be generated with the new random button, and the keep button records a sample of the color in the top window. These samples can then be selected with the left mouse button or deleted with the right button. When changing a color, use the apply button to make the choice take effect.