libSBML Python API  5.11.0
Layout

The libSBML “layout” extension implements support for the SBML Level 3 Layout package.

Introduction

The layout of a reaction network diagram should be described as graphical representations of species and reactions (and not as arbitrary drawing or graph). This means that existing languages for the description of vector drawings (SVG) or general graphs cannot be used. While it may seem unnecessary to invent a new language when an existing one like SVG could in principle be used to describe the layout of a reaction network, there are good reasons to have a language tailored specifically for the layout of SBML models. Presumably, most programs that will use this SBML extension are primarily programs dealing with biochemical models. Internally, they will have data structures for species and reactions, so it will be natural for them to describe the layout of the reaction network also in terms of species and reactions (and not in terms of, e.g., polygons or splines). Thus, the LayoutClass object defined by this SBML Layout package has a similar structure like the SBML Model object and contains lists of graphical representations of compartments, species, and reactions. Additional layout elements and relationships can be represented by using other custom objects defined by this package.

Example of different renderings of the same layout.

Another important question is the level of detail that the description should provide. For simplicity, only the layout (i.e., the position of the different graphical objects) of the diagram is encoded, not the details of how it should be rendered; the latter is left to the SBML Level 3 Render package. The figure at right illustrates this distinction. All three diagrams could be renderings of the same layout and would be described by identical SBML files. No information about colors, line styles, fonts, etc., is present in the layout description.

The next question is how the relation between the model and the layout should be established. There seems to be a consensus that one model element can be represented by several layout elements. For example, it can be useful to have several representations of one species in the layout to avoid crossing lines. This can be accomplished if every layout element has a field that refers to the id of a model element.

There are also cases where a layout element does not correspondent to exactly one model element. One example is when a layout shows a simplified version of a model in which one reaction in the layout corresponds to several reactions and intermediate species in the model. This is the reason why the field in the layout elements that refers to the model elements is optional: to allow layout objects that do not have a specific counterpart in the SBML model.

The result of all this is a way to describe the graphical layout of a reaction network in biochemical terms. This layout can be closely tied to the model. A graphical editor, for example, would typically create a layout that is closely connected (by a one-to-several relation from the model elements to the layout elements) to the model. A more general layout design program could create a layout that is not so closely tied to the model; for example, it could create a layout that shows a simplified version of the model.

Historical considerations

Historically, the SBML Layout package has been used to encode the layout of SBML Level 2 models; indeed, the original version of the package was developed in the context of SBML Level 2. The approach used with Level 2 is to store the layout information as SBML annotations, i.e., using SBML <annotation> elements. The following XML namespace must be used for layout annotations in Level 2 models:

http://projects.eml.org/bcb/sbml/level2

A minimal example in this case would look like the following:

<?xml version="1.0" encoding="UTF-8"?>
<sbml xmlns="http://www.sbml.org/sbml/level2" level="2" version="1">
  <model>
    <annotation>
      <listOfLayouts xmlns="http://projects.eml.org/bcb/sbml/level2">
        ...
      </listOfLayouts>
    </annotation>
  </model>
</sbml>

Special libSBML behavior for Level 2 Layout

Due to the way that the encoding difference discussed above affects legacy applications, libSBML implements special behavior for the Layout package: it always creates a Layout plugin object for any SBML Level 2 document it reads in, regardless of whether that document actually uses Layout constructs. This is unlike the case for SBML Level 3 documents that use Layout—for them, libSBML will not create a plugin object unless the document actually declares the use of the Layout package (via the usual Level 3 namespace declaration for Level 3 packages).

This has the following consequence. If an application queries for the presence of Layout in an SBML Level 2 document by testing only for the existence of the plugin object, it will always get a positive result; in other words, the presence of a Layout extension object is not an indication of whether a read-in Level 2 document does or does not use SBML Layout. Instead, callers have to query explicitly for the existence of layout information.

The special, always-available Level 2 Layout behavior was motivated by a desire to support legacy applications. In SBML Level 3, the Layout package uses the normal SBML Level 3 scheme of requiring declarations on the SBML document element. This means that upon reading a model, libSBML knows right away whether it contains layout information. In SBML Level 2, there is no top-level declaration because layout is stored as annotations in the body of the model. Detecting the presence of layout information when reading a Level 2 model requires parsing the annotations. For efficiency reasons, libSBML normally does not parse annotations automatically when reading a model. However, applications that predated the introduction of Level 3 Layout and the updated version of libSBML never had to do anything special to enable parsing layout; the facilities were always available for every Level 2 model as long as libSBML was compiled with Layout support. To avoid burdening developers of legacy applications with the need to modify their software, libSBML provides backward compatibility by always preloading the Layout package extension when reading Level 2 models. The same applies to the creation of Level 2 models: with the plugin-oriented libSBML, applications normally would have to take deliberate steps to activate package code, instantiate objects, manage namespaces, and so on. LibSBML again loads the Layout package plugin automatically when creating a Level 2 model, thereby making the APIs available to legacy applications without further work on their part.

Testing for Level 2 Layout

The following are examples of code fragments that could be used to test for the presence of layout data in a Level 2 model.

The specification for this SBML package

This API documentation for libSBML does not provide a complete explanation of the SBML Level 3 Layout (“layout”) package. If you are developing software that uses “layout”, you are strongly urged to read the actual specification for the package. A link to the specification document current is provided below, along with a link to the page of known issues (if any).

Specification for SBML Level 3 Layout, current at the time of this libSBML release (5.11.0). Note: an Internet connection is required to access these documents.
Specification (in PDF format) Known issues
Layout package, Version 1 Release 1 Errata page
More...

Classes

class  libsbml.BoundingBox
 layout A bounding box for an item in a diagram. More...
 
class  libsbml.CompartmentGlyph
 layout A glyph for an SBML compartment. More...
 
class  libsbml.CubicBezier
 layout A Cubic Bézier smooth curve. More...
 
class  libsbml.Curve
 layout A curve connecting elements in a diagram. More...
 
class  libsbml.Dimensions
 layout Spatial dimensions of a 2D or 3D shape. More...
 
class  libsbml.GeneralGlyph
 layout A glyph for miscellaneous items. More...
 
class  libsbml.GraphicalObject
 layout Base class of objects that store layouts. More...
 
class  libsbml.Layout
 layout The layout of a diagram of an SBML model. More...
 
class  libsbml.LayoutExtension
 layout Base extension class for the package. More...
 
class  libsbml.LayoutModelPlugin
 layout Extension of Model. More...
 
class  libsbml.LayoutPkgNamespaces
 layout SBMLNamespaces extension for the package. More...
 
class  libsbml.LayoutSpeciesReferencePlugin
 layout Extension of SpeciesReference. More...
 
class  libsbml.LineSegment
 layout Representation of a line. More...
 
class  libsbml.ListOfCompartmentGlyphs
 layout A list of CompartmentGlyph objects. More...
 
class  libsbml.ListOfGraphicalObjects
 layout A list of GraphicalObject objects. More...
 
class  libsbml.ListOfLayouts
 layout A list of Layout objects. More...
 
class  libsbml.ListOfLineSegments
 layout A list of LineSegment objects. More...
 
class  libsbml.ListOfReactionGlyphs
 layout A list of ReactionGlyph objects. More...
 
class  libsbml.ListOfReferenceGlyphs
 layout A list of ReferenceGlyph objects. More...
 
class  libsbml.ListOfSpeciesGlyphs
 layout A list of SpeciesGlyph objects. More...
 
class  libsbml.ListOfSpeciesReferenceGlyphs
 layout A list of SpeciesReferenceGlyph objects. More...
 
class  libsbml.ListOfTextGlyphs
 layout A list of TextGlyph objects. More...
 
class  libsbml.Point
 layout Representation of a point. More...
 
class  libsbml.ReactionGlyph
 layout A glyph for an SBML reaction. More...
 
class  libsbml.ReferenceGlyph
 layout Connection between an object and a glyph. More...
 
class  libsbml.SpeciesGlyph
 layout A glyph for an SBML species. More...
 
class  libsbml.SpeciesReferenceGlyph
 layout A glyph for an SBML species reference. More...
 
class  libsbml.TextGlyph
 layout A glyph for a text label. More...
 

Functions

def libsbml.Point.__init__ (self, args)
 layout Representation of a point. More...
 
def libsbml.Dimensions.__init__ (self, args)
 layout Spatial dimensions of a 2D or 3D shape. More...
 
def libsbml.BoundingBox.__init__ (self, args)
 layout A bounding box for an item in a diagram. More...
 
def libsbml.GraphicalObject.__init__ (self, args)
 layout Base class of objects that store layouts. More...
 
def libsbml.CompartmentGlyph.__init__ (self, args)
 layout A glyph for an SBML compartment. More...
 
def libsbml.LineSegment.__init__ (self, args)
 layout Representation of a line. More...
 
def libsbml.CubicBezier.__init__ (self, args)
 layout A Cubic Bézier smooth curve. More...
 
def libsbml.Curve.__init__ (self, args)
 layout A curve connecting elements in a diagram. More...
 
def libsbml.SpeciesReferenceGlyph.__init__ (self, args)
 layout A glyph for an SBML species reference. More...
 
def libsbml.ReferenceGlyph.__init__ (self, args)
 layout Connection between an object and a glyph. More...
 
def libsbml.GeneralGlyph.__init__ (self, args)
 layout A glyph for miscellaneous items. More...
 
def libsbml.ReactionGlyph.__init__ (self, args)
 layout A glyph for an SBML reaction. More...
 
def libsbml.SpeciesGlyph.__init__ (self, args)
 layout A glyph for an SBML species. More...
 
def libsbml.TextGlyph.__init__ (self, args)
 layout A glyph for a text label. More...
 
def libsbml.Layout.__init__ (self, args)
 layout The layout of a diagram of an SBML model. More...
 
def libsbml.LayoutModelPlugin.__init__ (self, args)
 layout Extension of Model. More...
 
def libsbml.LayoutSpeciesReferencePlugin.__init__ (self, args)
 layout Extension of SpeciesReference. More...
 
def libsbml.ListOfGraphicalObjects.clone (self)
 layout A list of GraphicalObject objects. More...
 
def libsbml.ListOfLineSegments.clone (self)
 layout A list of LineSegment objects. More...
 
def libsbml.ListOfReferenceGlyphs.clone (self)
 layout A list of ReferenceGlyph objects. More...
 
def libsbml.ListOfSpeciesReferenceGlyphs.clone (self)
 layout A list of SpeciesReferenceGlyph objects. More...
 
def libsbml.ListOfCompartmentGlyphs.clone (self)
 layout A list of CompartmentGlyph objects. More...
 
def libsbml.ListOfSpeciesGlyphs.clone (self)
 layout A list of SpeciesGlyph objects. More...
 
def libsbml.ListOfReactionGlyphs.clone (self)
 layout A list of ReactionGlyph objects. More...
 
def libsbml.ListOfTextGlyphs.clone (self)
 layout A list of TextGlyph objects. More...
 
def libsbml.ListOfLayouts.clone (self)
 layout A list of Layout objects. More...
 
def libsbml.LayoutExtension.getPackageName ()
 layout Base extension class for the package. More...
 

Detailed Description

The libSBML “layout” extension implements support for the SBML Level 3 Layout package.

Introduction

The layout of a reaction network diagram should be described as graphical representations of species and reactions (and not as arbitrary drawing or graph). This means that existing languages for the description of vector drawings (SVG) or general graphs cannot be used. While it may seem unnecessary to invent a new language when an existing one like SVG could in principle be used to describe the layout of a reaction network, there are good reasons to have a language tailored specifically for the layout of SBML models. Presumably, most programs that will use this SBML extension are primarily programs dealing with biochemical models. Internally, they will have data structures for species and reactions, so it will be natural for them to describe the layout of the reaction network also in terms of species and reactions (and not in terms of, e.g., polygons or splines). Thus, the LayoutClass object defined by this SBML Layout package has a similar structure like the SBML Model object and contains lists of graphical representations of compartments, species, and reactions. Additional layout elements and relationships can be represented by using other custom objects defined by this package.

Example of different renderings of the same layout.

Another important question is the level of detail that the description should provide. For simplicity, only the layout (i.e., the position of the different graphical objects) of the diagram is encoded, not the details of how it should be rendered; the latter is left to the SBML Level 3 Render package. The figure at right illustrates this distinction. All three diagrams could be renderings of the same layout and would be described by identical SBML files. No information about colors, line styles, fonts, etc., is present in the layout description.

The next question is how the relation between the model and the layout should be established. There seems to be a consensus that one model element can be represented by several layout elements. For example, it can be useful to have several representations of one species in the layout to avoid crossing lines. This can be accomplished if every layout element has a field that refers to the id of a model element.

There are also cases where a layout element does not correspondent to exactly one model element. One example is when a layout shows a simplified version of a model in which one reaction in the layout corresponds to several reactions and intermediate species in the model. This is the reason why the field in the layout elements that refers to the model elements is optional: to allow layout objects that do not have a specific counterpart in the SBML model.

The result of all this is a way to describe the graphical layout of a reaction network in biochemical terms. This layout can be closely tied to the model. A graphical editor, for example, would typically create a layout that is closely connected (by a one-to-several relation from the model elements to the layout elements) to the model. A more general layout design program could create a layout that is not so closely tied to the model; for example, it could create a layout that shows a simplified version of the model.

Historical considerations

Historically, the SBML Layout package has been used to encode the layout of SBML Level 2 models; indeed, the original version of the package was developed in the context of SBML Level 2. The approach used with Level 2 is to store the layout information as SBML annotations, i.e., using SBML <annotation> elements. The following XML namespace must be used for layout annotations in Level 2 models:

http://projects.eml.org/bcb/sbml/level2

A minimal example in this case would look like the following:

<?xml version="1.0" encoding="UTF-8"?>
<sbml xmlns="http://www.sbml.org/sbml/level2" level="2" version="1">
  <model>
    <annotation>
      <listOfLayouts xmlns="http://projects.eml.org/bcb/sbml/level2">
        ...
      </listOfLayouts>
    </annotation>
  </model>
</sbml>

Special libSBML behavior for Level 2 Layout

Due to the way that the encoding difference discussed above affects legacy applications, libSBML implements special behavior for the Layout package: it always creates a Layout plugin object for any SBML Level 2 document it reads in, regardless of whether that document actually uses Layout constructs. This is unlike the case for SBML Level 3 documents that use Layout—for them, libSBML will not create a plugin object unless the document actually declares the use of the Layout package (via the usual Level 3 namespace declaration for Level 3 packages).

This has the following consequence. If an application queries for the presence of Layout in an SBML Level 2 document by testing only for the existence of the plugin object, it will always get a positive result; in other words, the presence of a Layout extension object is not an indication of whether a read-in Level 2 document does or does not use SBML Layout. Instead, callers have to query explicitly for the existence of layout information.

The special, always-available Level 2 Layout behavior was motivated by a desire to support legacy applications. In SBML Level 3, the Layout package uses the normal SBML Level 3 scheme of requiring declarations on the SBML document element. This means that upon reading a model, libSBML knows right away whether it contains layout information. In SBML Level 2, there is no top-level declaration because layout is stored as annotations in the body of the model. Detecting the presence of layout information when reading a Level 2 model requires parsing the annotations. For efficiency reasons, libSBML normally does not parse annotations automatically when reading a model. However, applications that predated the introduction of Level 3 Layout and the updated version of libSBML never had to do anything special to enable parsing layout; the facilities were always available for every Level 2 model as long as libSBML was compiled with Layout support. To avoid burdening developers of legacy applications with the need to modify their software, libSBML provides backward compatibility by always preloading the Layout package extension when reading Level 2 models. The same applies to the creation of Level 2 models: with the plugin-oriented libSBML, applications normally would have to take deliberate steps to activate package code, instantiate objects, manage namespaces, and so on. LibSBML again loads the Layout package plugin automatically when creating a Level 2 model, thereby making the APIs available to legacy applications without further work on their part.

Testing for Level 2 Layout

The following are examples of code fragments that could be used to test for the presence of layout data in a Level 2 model.

The specification for this SBML package

This API documentation for libSBML does not provide a complete explanation of the SBML Level 3 Layout (“layout”) package. If you are developing software that uses “layout”, you are strongly urged to read the actual specification for the package. A link to the specification document current is provided below, along with a link to the page of known issues (if any).

Specification for SBML Level 3 Layout, current at the time of this libSBML release (5.11.0). Note: an Internet connection is required to access these documents.
Specification (in PDF format) Known issues
Layout package, Version 1 Release 1 Errata page

Function Documentation

def libsbml.Point.__init__ (   self,
  args 
)

layout Representation of a point.

A point is specified via the required attributes 'x', 'y' and an optional attribute 'z', all of which are of type float. If the attribute z is not specified, the object is a two dimensional object. The Point class also has an optional attribute id of type SId. While not used in the “layout” package, it can be used by programs to refer to the elements.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   Point
__init__(long level, long version)   Point
__init__(long level)   Point
__init__()   Point
__init__(LayoutPkgNamespaces layoutns)   Point
__init__(Point orig)   Point
__init__(LayoutPkgNamespaces layoutns, float x, float y, float z=0.0)   Point
__init__(LayoutPkgNamespaces layoutns, float x, float y)   Point
__init__(XMLNode node, long l2version=4)   Point
__init__(XMLNode node)   Point

Each variant is described separately below.


Method variant with the following signature:
Point(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new point with x,y and z set to 0.0.


Method variant with the following signature:
Point(XMLNode node, long l2version = 4)

Creates a new Point from the given XMLNode


Method variant with the following signature:
Point(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
Point(LayoutPkgNamespaces layoutns, float x, float y, float z =0.0)

Creates a new point with the given coordinates.


Method variant with the following signature:
Point(Point orig)

Copy constructor.

def libsbml.Dimensions.__init__ (   self,
  args 
)

layout Spatial dimensions of a 2D or 3D shape.

A dimension is specified via the required attributes width, height and an optional attribute depth, all of which are of type float. If the attribute depth is not specified, the object is a two dimensional object. The width attribute of Dimensions specifies the size of the object in the direction of the positive x axis, the height attribute specifies the size of the object along the positive y axis and the depth attribute specifies the size of the object along the positive z axis. All sizes for Dimensions objects are positive values, and so the attributes are not allowed to take negative values. The Dimensions class also has an optional attribute id of type SId. While not used in the “layout” package, it can be used by programs to refer to the elements.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   Dimensions
__init__(long level, long version)   Dimensions
__init__(long level)   Dimensions
__init__()   Dimensions
__init__(LayoutPkgNamespaces layoutns)   Dimensions
__init__(Dimensions orig)   Dimensions
__init__(LayoutPkgNamespaces layoutns, float w, float h, float d=0.0)   Dimensions
__init__(LayoutPkgNamespaces layoutns, float w, float h)   Dimensions
__init__(XMLNode node, long l2version=4)   Dimensions
__init__(XMLNode node)   Dimensions

Each variant is described separately below.


Method variant with the following signature:
Dimensions(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new Dimensions object with the given level, version, and package version and with all sizes set to 0.0.


Method variant with the following signature:
Dimensions(Dimensions orig)

Copy constructor.


Method variant with the following signature:
Dimensions(LayoutPkgNamespaces layoutns, float w, float h, float d = 0.0)

Creates a new Dimensions object with the given sizes.


Method variant with the following signature:
Dimensions(LayoutPkgNamespaces layoutns)

Creates a new Dimensions object with the given LayoutPkgNamespaces object.


Method variant with the following signature:
Dimensions(XMLNode node, long l2version = 4)

Creates a new Dimensions object from the given XMLNode

def libsbml.BoundingBox.__init__ (   self,
  args 
)

layout A bounding box for an item in a diagram.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   BoundingBox
__init__(long level, long version)   BoundingBox
__init__(long level)   BoundingBox
__init__()   BoundingBox
__init__(LayoutPkgNamespaces layoutns)   BoundingBox
__init__(BoundingBox orig)   BoundingBox
__init__(LayoutPkgNamespaces layoutns, string id)   BoundingBox
__init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float width, float height)   BoundingBox
__init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float width, float height, float depth)   BoundingBox
__init__(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)   BoundingBox
__init__(XMLNode node, long l2version=4)   BoundingBox
__init__(XMLNode node)   BoundingBox

Each variant is described separately below.


Method variant with the following signature:
BoundingBox(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)

Constructor which sets the id, the coordinates and the dimensions to the given values.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
BoundingBox(BoundingBox orig)

Copy constructor.


Method variant with the following signature:
BoundingBox(LayoutPkgNamespaces layoutns, string id)

Constructor set position and dimensions to (0.0,0.0,0.0) and the id to a copy of the given string.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
BoundingBox(LayoutPkgNamespaces layoutns)

Creates a new BoundingBox object with the given LayoutPkgNamespaces object.


Method variant with the following signature:
BoundingBox(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float width, float height, float depth)

Constructor which sets the id, the coordinates and the dimensions to the given 3D values.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
BoundingBox(LayoutPkgNamespaces layoutns, string id, float x, float y, float width, float height)

Constructor which sets the id, the coordinates and the dimensions to the given 2D values.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
BoundingBox(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Default Constructor set position and dimensions to (0.0,0.0,0.0) and the id to an empty string.


Method variant with the following signature:
BoundingBox(XMLNode node, long l2version=4)

Creates a new BoundingBox from the given XMLNode

(FOR BACKWARD COMPATIBILITY)

def libsbml.GraphicalObject.__init__ (   self,
  args 
)

layout Base class of objects that store layouts.

All the more specific layout elements (CompartmentGlyph, GeneralGlyph, SpeciesGlyph, ReactionGlyph, ReferenceGlyph, TextGlyph, and SpeciesReferenceGlyph) are derived from the class GraphicalObject. Each object of class GraphicalObject has a mandatory BoundingBox, which specifies the position and the size of the object. While GraphicalObject is the base class for most elements in the “layout” package, it is not an abstract class. It can be instantiated when used in the listOfAdditionalGraphicalObjects to describe additional elements and relationships. Since it only describes a BoundingBox, programs are encouraged to add Annotation objects that describe program-specific graphical information.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   GraphicalObject
__init__(long level, long version)   GraphicalObject
__init__(long level)   GraphicalObject
__init__()   GraphicalObject
__init__(LayoutPkgNamespaces layoutns)   GraphicalObject
__init__(LayoutPkgNamespaces layoutns, string id)   GraphicalObject
__init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float w, float h)   GraphicalObject
__init__(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float w, float h, float d)   GraphicalObject
__init__(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)   GraphicalObject
__init__(LayoutPkgNamespaces layoutns, string id, BoundingBox bb)   GraphicalObject
__init__(XMLNode node, long l2version=4)   GraphicalObject
__init__(XMLNode node)   GraphicalObject
__init__(GraphicalObject source)   GraphicalObject

Each variant is described separately below.


Method variant with the following signature:
GraphicalObject(XMLNode node, long l2version=4)

Creates a new GraphicalObject from the given XMLNode

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns, string id)

Creates a new GraphicalObject with the given id.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns)

Creates a new GraphicalObject with the given LayoutPkgNamespaces


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns, string id, Point p, Dimensions d)

Creates a new GraphicalObject with the given id and 3D coordinates for the bounding box.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GraphicalObject(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new GraphicalObject.


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns, string id, BoundingBox bb)

Creates a new GraphicalObject with the given id and 3D coordinates for the bounding box.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns, string id, float x, float y, float z, float w, float h, float d)

Creates a new GraphicalObject with the given id and 3D coordinates for the bounding box.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GraphicalObject(GraphicalObject source)

Copy constructor.


Method variant with the following signature:
GraphicalObject(LayoutPkgNamespaces layoutns, string id, float x, float y, float w, float h)

Creates a new GraphicalObject with the given id and 2D coordinates for the bounding box.

(FOR BACKWARD COMPATIBILITY)

def libsbml.CompartmentGlyph.__init__ (   self,
  args 
)

layout A glyph for an SBML compartment.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   CompartmentGlyph
__init__(long level, long version)   CompartmentGlyph
__init__(long level)   CompartmentGlyph
__init__()   CompartmentGlyph
__init__(LayoutPkgNamespaces layoutns)   CompartmentGlyph
__init__(LayoutPkgNamespaces layoutns, string id)   CompartmentGlyph
__init__(LayoutPkgNamespaces layoutns, string id, string compartmentId)   CompartmentGlyph
__init__(XMLNode node, long l2version=4)   CompartmentGlyph
__init__(XMLNode node)   CompartmentGlyph
__init__(CompartmentGlyph source)   CompartmentGlyph

Each variant is described separately below.


Method variant with the following signature:
CompartmentGlyph(LayoutPkgNamespaces layoutns, string id, string compartmentId)

Constructor which creates a new CompartmentGlyph. Id and associated compartment id are set to copies of the values given as arguments.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CompartmentGlyph(LayoutPkgNamespaces layoutns, string id)

Constructor which creates a new CompartmentGlyph with the given id.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CompartmentGlyph(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
CompartmentGlyph(CompartmentGlyph source)

Copy constructor.


Method variant with the following signature:
CompartmentGlyph(XMLNode node, long l2version=4)

Creates a new CompartmentGlyph from the given XMLNode

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CompartmentGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Default Constructor which creates a new CompartmentGlyph. Id and associated compartment id are unset.

def libsbml.LineSegment.__init__ (   self,
  args 
)

layout Representation of a line.

The LineSegment class consists of the mandatory attribute xsi:type and two child elements of type Point. One is called 'start' and represents the starting point of the line, the other is called 'end' and represents the endpoint of the line. The LineSegment class is also the base class for CubicBezier, which represent curved lines instead of straight ones.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   LineSegment
__init__(long level, long version)   LineSegment
__init__(long level)   LineSegment
__init__()   LineSegment
__init__(LayoutPkgNamespaces layoutns)   LineSegment
__init__(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)   LineSegment
__init__(LineSegment orig)   LineSegment
__init__(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)   LineSegment
__init__(LayoutPkgNamespaces layoutns, Point start, Point end)   LineSegment
__init__(XMLNode node, long l2version=4)   LineSegment
__init__(XMLNode node)   LineSegment

Each variant is described separately below.


Method variant with the following signature:
LineSegment(LayoutPkgNamespaces layoutns, Point start, Point end)

Creates a new line segment with the two given points.


Method variant with the following signature:
LineSegment(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)

Creates a new line segment with the given 2D coordinates.


Method variant with the following signature:
LineSegment(LayoutPkgNamespaces layoutns)

Creates a line segment with the LayoutPkgNamespaces and both points set to (0.0,0.0,0.0)


Method variant with the following signature:
LineSegment(XMLNode node, long l2version=4)

Creates a new LineSegment from the given XMLNode


Method variant with the following signature:
LineSegment(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a line segment with the given SBML level, version, and package version and both points set to (0.0,0.0,0.0)


Method variant with the following signature:
LineSegment(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)

Creates a new line segment with the given 3D coordinates.


Method variant with the following signature:
LineSegment(LineSegment orig)

Copy constructor.

def libsbml.CubicBezier.__init__ (   self,
  args 
)

layout A Cubic Bézier smooth curve.

In order to be able to represent smooth curves the “layout” package defines the class CubicBezier. It represents a Bezier curve, and is readily available in most graphics APIs. The class CubicBezier is derived from LineSegment. It consists of four elements: the two inherited elements 'start' and 'end', which specify the starting point and the endpoint of the cubic bezier curve, and two elements 'basePoint1' and 'basePoint2', which specify the two additional base points that are needed to describe a cubic bezier curve.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   CubicBezier
__init__(long level, long version)   CubicBezier
__init__(long level)   CubicBezier
__init__()   CubicBezier
__init__(LayoutPkgNamespaces layoutns)   CubicBezier
__init__(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)   CubicBezier
__init__(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)   CubicBezier
__init__(CubicBezier orig)   CubicBezier
__init__(LayoutPkgNamespaces layoutns, Point start, Point end)   CubicBezier
__init__(LayoutPkgNamespaces layoutns, Point start, Point base1, Point base2, Point end)   CubicBezier
__init__(XMLNode node, long l2version=4)   CubicBezier
__init__(XMLNode node)   CubicBezier

Each variant is described separately below.


Method variant with the following signature:
CubicBezier(LayoutPkgNamespaces layoutns, Point start, Point end)

Creates a CubicBezier with the given points and returns the pointer.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CubicBezier(LayoutPkgNamespaces layoutns, float x1, float y1, float x2, float y2)

Creates a CubicBezier with the given 2D coordinates and returns the pointer.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CubicBezier(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
CubicBezier(XMLNode node, long l2version=4)

Creates a new Layout from the given XMLNode

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CubicBezier(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a CubicBezier and returns the pointer.


Method variant with the following signature:
CubicBezier(LayoutPkgNamespaces layoutns, Point start, Point base1, Point base2, Point end)

Creates a CubicBezier with the given points and returns the pointer.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CubicBezier(LayoutPkgNamespaces layoutns, float x1, float y1, float z1, float x2, float y2, float z2)

Creates a CubicBezier with the given 3D coordinates and returns the pointer.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
CubicBezier(CubicBezier orig)

Copy constructor.

(FOR BACKWARD COMPATIBILITY)

def libsbml.Curve.__init__ (   self,
  args 
)

layout A curve connecting elements in a diagram.

The Curve class describes how to connect elements in a diagram defined with the use of the “layout” package. A curve is fully specified by a mandatory listOfCurveSegments element and is used in four places in the “layout” package:

  • ReactionGlyph: Here it describes a curve for the center piece of a reaction.
  • GeneralGlyph: Here it describes a curve for the center piece of an additional relationship.

In the text above, the term 'center piece' refers to either the Curve element of a ReactionGlyph, or its BoundingBox.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   Curve
__init__(long level, long version)   Curve
__init__(long level)   Curve
__init__()   Curve
__init__(LayoutPkgNamespaces layoutns)   Curve
__init__(XMLNode node, long l2version=4)   Curve
__init__(XMLNode node)   Curve
__init__(Curve source)   Curve

Each variant is described separately below.


Method variant with the following signature:
Curve(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a curve with an empty list of segments.


Method variant with the following signature:
Curve(Curve source)

Copy constructor.


Method variant with the following signature:
Curve(LayoutPkgNamespaces layoutns)

Creates a new Curve with the given LayoutPkgNamespaces object.


Method variant with the following signature:
Curve(XMLNode node, long l2version=4)

Creates a new Curve from the given XMLNode

def libsbml.SpeciesReferenceGlyph.__init__ (   self,
  args 
)

layout A glyph for an SBML species reference.

The SpeciesReferenceGlyph element describes the graphical connection between a SpeciesGlyph and a ReactionGlyph (which would be an arrow or some curve in most cases). A SpeciesReferenceGlyph inherits from GraphicalObject, and adds a mandatory attribute 'speciesGlyph' and two optional attributes 'speciesReference' and 'role'. Optionally, the SpeciesReferenceGlyph also has a child element 'curve'.

If the curve is specified, it overrides the inherited bounding box.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   SpeciesReferenceGlyph
__init__(long level, long version)   SpeciesReferenceGlyph
__init__(long level)   SpeciesReferenceGlyph
__init__()   SpeciesReferenceGlyph
__init__(LayoutPkgNamespaces layoutns)   SpeciesReferenceGlyph
__init__(LayoutPkgNamespaces layoutns, string sid, string speciesGlyphId, string speciesReferenceId, long role)   SpeciesReferenceGlyph
__init__(XMLNode node, long l2version=4)   SpeciesReferenceGlyph
__init__(XMLNode node)   SpeciesReferenceGlyph
__init__(SpeciesReferenceGlyph source)   SpeciesReferenceGlyph

Each variant is described separately below.


Method variant with the following signature:
SpeciesReferenceGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new SpeciesReferenceGlyph with the given SBML level, version and package version. The id if the associated species reference and the id of the associated species glyph are set to the empty string. The role is set to SPECIES_ROLE_UNDEFINED.


Method variant with the following signature:
SpeciesReferenceGlyph(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
SpeciesReferenceGlyph(SpeciesReferenceGlyph source)

Copy constructor.


Method variant with the following signature:
SpeciesReferenceGlyph(LayoutPkgNamespaces layoutns, string sid, string speciesGlyphId, string speciesReferenceId, long role)

Creates a new SpeciesReferenceGlyph. The id is given as the first argument, the id of the associated species glyph is given as the second argument. The third argument is the id of the associated species reference and the fourth argument is the role.


Method variant with the following signature:
SpeciesReferenceGlyph(XMLNode node, long l2version=4)

Creates a new SpeciesReferenceGlyph from the given XMLNode

def libsbml.ReferenceGlyph.__init__ (   self,
  args 
)

layout Connection between an object and a glyph.

The ReferenceGlyph element describes the graphical connection between an arbitrary GraphicalObject (or derived element) and a GeneralGlyph (which would be an arrow or some curve in most cases). A ReferenceGlyph inherits from GraphicalObject. Additionally it has a mandatory attribute 'glyph' and two optional attributes 'reference' and 'role'. Optionally, the ReferenceGlyph also has an element 'curve'. The ReferenceGlyph should either contain a bounding box or a curve specification. If both are given, the bounding box should be ignored.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   ReferenceGlyph
__init__(long level, long version)   ReferenceGlyph
__init__(long level)   ReferenceGlyph
__init__()   ReferenceGlyph
__init__(LayoutPkgNamespaces layoutns)   ReferenceGlyph
__init__(LayoutPkgNamespaces layoutns, string sid, string glyphId, string referenceId, string role)   ReferenceGlyph
__init__(XMLNode node, long l2version=4)   ReferenceGlyph
__init__(XMLNode node)   ReferenceGlyph
__init__(ReferenceGlyph source)   ReferenceGlyph

Each variant is described separately below.


Method variant with the following signature:
ReferenceGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new ReferenceGlyph with the given SBML level, version and package version. The id if the associated reference and the id of the associated glyph are set to the empty string. The role is set to empty.


Method variant with the following signature:
ReferenceGlyph(LayoutPkgNamespaces layoutns, string sid, string glyphId, string referenceId, string role)

Creates a new ReferenceGlyph. The id is given as the first argument, the id of the associated glyph is given as the second argument. The third argument is the id of the associated reference and the fourth argument is the role.


Method variant with the following signature:
ReferenceGlyph(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
ReferenceGlyph(ReferenceGlyph source)

Copy constructor.


Method variant with the following signature:
ReferenceGlyph(XMLNode node, long l2version=4)

Creates a new ReferenceGlyph from the given XMLNode

def libsbml.GeneralGlyph.__init__ (   self,
  args 
)

layout A glyph for miscellaneous items.

The GeneralGlyph is used to facilitate the representation of elements other than Compartment, Species and Reaction and thus can be used for the display of relationships of Rule or elements defined by other SBML packages. It closely follows the structure of the ReactionGlyph. GeneralGlyph is defined to have an optional attribute reference as well as the elements curve, listOfReferenceGlyphs and listOfSubGlyphs.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   GeneralGlyph
__init__(long level, long version)   GeneralGlyph
__init__(long level)   GeneralGlyph
__init__()   GeneralGlyph
__init__(LayoutPkgNamespaces layoutns)   GeneralGlyph
__init__(LayoutPkgNamespaces layoutns, string id)   GeneralGlyph
__init__(LayoutPkgNamespaces layoutns, string id, string referenceId)   GeneralGlyph
__init__(XMLNode node, long l2version=4)   GeneralGlyph
__init__(XMLNode node)   GeneralGlyph
__init__(GeneralGlyph source)   GeneralGlyph

Each variant is described separately below.


Method variant with the following signature:
GeneralGlyph(GeneralGlyph source)

Copy constructor.


Method variant with the following signature:
GeneralGlyph(LayoutPkgNamespaces layoutns, string id, string referenceId)

Creates a glyph with the given LayoutPkgNamespaces, id and set the id of the associated element to the second argument.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GeneralGlyph(LayoutPkgNamespaces layoutns, string id)

Creates a glyph with the given LayoutPkgNamespaces and id.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
GeneralGlyph(LayoutPkgNamespaces layoutns)

Creates a new GeneralGlyph with the given LayoutPkgNamespaces object.


Method variant with the following signature:
GeneralGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new GeneralGlyph. The list of reference glyph and subglyphs is empty and the id of the associated element is set to the empty string.


Method variant with the following signature:
GeneralGlyph(XMLNode node, long l2version = 4)

Creates a new GeneralGlyph from the given XMLNode

(FOR BACKWARD COMPATIBILITY)

def libsbml.ReactionGlyph.__init__ (   self,
  args 
)

layout A glyph for an SBML reaction.

Analogous to how a Reaction object has to at least have one reactant or product, the ReactionGlyph has to at least have one SpeciesReferenceGlyph stored in the ListOfSpeciesReferenceGlyphs. Figure 12 on the following page provides the UML diagram for the class definition. The ReactionGlyph inherits from GraphicalObject. In addition to the attributes inherited from GraphicalObject, the ReactionGlyph is described by an attribute reaction, a Curve element and a listOfSpeciesReferenceGlyphs element. The Curve describes the center section of a ReactionGlyph. The center section is frequently used by tools to separate the point where substrates arcs come together, from the point where product arcs split off. The Curve is optional, and when not present the dimensions of the inherited BoundingBox describes the center section, by storing its position and dimension.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   ReactionGlyph
__init__(long level, long version)   ReactionGlyph
__init__(long level)   ReactionGlyph
__init__()   ReactionGlyph
__init__(LayoutPkgNamespaces layoutns)   ReactionGlyph
__init__(LayoutPkgNamespaces layoutns, string id)   ReactionGlyph
__init__(LayoutPkgNamespaces layoutns, string id, string reactionId)   ReactionGlyph
__init__(XMLNode node, long l2version=4)   ReactionGlyph
__init__(XMLNode node)   ReactionGlyph
__init__(ReactionGlyph source)   ReactionGlyph

Each variant is described separately below.


Method variant with the following signature:
ReactionGlyph(ReactionGlyph source)

Copy constructor.


Method variant with the following signature:
ReactionGlyph(LayoutPkgNamespaces layoutns, string id)

Creates a ResctionGlyph with the given LayoutPkgNamespaces and id.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
ReactionGlyph(LayoutPkgNamespaces layoutns)

Creates a new ReactionGlyph with the given LayoutPkgNamespaces object.


Method variant with the following signature:
ReactionGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new ReactionGlyph. The list of species reference glyph is empty and the id of the associated reaction is set to the empty string.


Method variant with the following signature:
ReactionGlyph(LayoutPkgNamespaces layoutns, string id, string reactionId)

Creates a ResctionGlyph with the given LayoutPkgNamespaces, id and set the id of the associated reaction to the second argument.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
ReactionGlyph(XMLNode node, long l2version = 4)

Creates a new ReactionGlyph from the given XMLNode

(FOR BACKWARD COMPATIBILITY)

def libsbml.SpeciesGlyph.__init__ (   self,
  args 
)

layout A glyph for an SBML species.

In addition to the attributes it inherits from GraphicalObject, the SpeciesGlyph object has an optional 'species' attribute.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   SpeciesGlyph
__init__(long level, long version)   SpeciesGlyph
__init__(long level)   SpeciesGlyph
__init__()   SpeciesGlyph
__init__(LayoutPkgNamespaces layoutns)   SpeciesGlyph
__init__(LayoutPkgNamespaces layoutns, string id)   SpeciesGlyph
__init__(LayoutPkgNamespaces layoutns, string id, string speciesId)   SpeciesGlyph
__init__(XMLNode node, long l2version=4)   SpeciesGlyph
__init__(XMLNode node)   SpeciesGlyph
__init__(SpeciesGlyph source)   SpeciesGlyph

Each variant is described separately below.


Method variant with the following signature:
SpeciesGlyph(LayoutPkgNamespaces layoutns, string id)

Creates a new SpeciesGlyph with the given id.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
SpeciesGlyph(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
SpeciesGlyph(LayoutPkgNamespaces layoutns, string id, string speciesId)

Creates a new SpeciesGlyph with the given id and the id of the associated species object set to the second argument.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
SpeciesGlyph(XMLNode node, long l2version=4)

Creates a new SpeciesGlyph from the given XMLNode


Method variant with the following signature:
SpeciesGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new SpeciesGlyph with the given SBML level, version, and package version and the id of the associated species set to the empty string.


Method variant with the following signature:
SpeciesGlyph(SpeciesGlyph source)

Copy constructor.

def libsbml.TextGlyph.__init__ (   self,
  args 
)

layout A glyph for a text label.

The TextGlyph class describes the position and dimension of text labels in the “layout” package. It inherits from GraphicalObject and adds the attributes graphicalObject, text and originOfText.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   TextGlyph
__init__(long level, long version)   TextGlyph
__init__(long level)   TextGlyph
__init__()   TextGlyph
__init__(LayoutPkgNamespaces layoutns)   TextGlyph
__init__(LayoutPkgNamespaces layoutns, string id)   TextGlyph
__init__(LayoutPkgNamespaces layoutns, string id, string text)   TextGlyph
__init__(XMLNode node, long l2version=4)   TextGlyph
__init__(XMLNode node)   TextGlyph
__init__(TextGlyph source)   TextGlyph

Each variant is described separately below.


Method variant with the following signature:
TextGlyph(LayoutPkgNamespaces layoutns, string id)

Creates a new TextGlyph. The id is given as the first argument.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
TextGlyph(LayoutPkgNamespaces layoutns)

Ctor.


Method variant with the following signature:
TextGlyph(XMLNode node, long l2version=4)

Creates a new TextGlyph from the given XMLNode

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
TextGlyph(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new TextGlyph with the given SBML level, versin and package version. The ids of the associated GraphicalObject and the originOfText are set to the empty string. The actual text is set to the empty string as well.


Method variant with the following signature:
TextGlyph(TextGlyph source)

Copy constructor.


Method variant with the following signature:
TextGlyph(LayoutPkgNamespaces layoutns, string id, string text)

Creates a new TextGlyph. The id is given as the first argument, the text to be displayed as the second. All other attirbutes are set to the empty string.

(FOR BACKWARD COMPATIBILITY)

def libsbml.Layout.__init__ (   self,
  args 
)

layout The layout of a diagram of an SBML model.

The Layout class stores layout information for some or all elements of the SBML model as well as additional objects that need not be connected to the model. The Layout has two attributes: id and name. Additionally, a Dimensions element specifies the size of the layout. The actual layout elements are contained in several lists, namely: a ListOfCompartmentGlyphs, a ListOfSpeciesGlyphs, a ListOfReactionGlyphs, a ListOfTextGlyphs, and a ListOfAdditionalGraphicalObjects. Each of these lists can only occur once, and, if present, are not allowed to be empty.

This method has multiple variants; they differ in the arguments they accept.

__init__(long level, long version, long pkgVersion)   Layout
__init__(long level, long version)   Layout
__init__(long level)   Layout
__init__()   Layout
__init__(LayoutPkgNamespaces layoutns)   Layout
__init__(LayoutPkgNamespaces layoutns, string id, Dimensions dimensions)   Layout
__init__(XMLNode node, long l2version=4)   Layout
__init__(XMLNode node)   Layout
__init__(Layout source)   Layout

Each variant is described separately below.


Method variant with the following signature:
Layout(long level = LayoutExtension.getDefaultLevel(), long version = LayoutExtension.getDefaultVersion(), long pkgVersion = LayoutExtension.getDefaultPackageVersion())

Creates a new Layout with the given level, version, and package version.


Method variant with the following signature:
Layout(LayoutPkgNamespaces layoutns)

Creates a new Layout with the given LayoutPkgNamespaces object.


Method variant with the following signature:
Layout(LayoutPkgNamespaces layoutns, string id, Dimensions dimensions)

Creates a new Layout with the given id and dimensions.

(FOR BACKWARD COMPATIBILITY)


Method variant with the following signature:
Layout(Layout source)

Copy constructor.


Method variant with the following signature:
Layout(XMLNode node, long l2version = 4)

Creates a new Layout from the given XMLNode (only for SBML Level2)

(FOR BACKWARD COMPATIBILITY)

def libsbml.LayoutModelPlugin.__init__ (   self,
  args 
)

layout Extension of Model.

This method has multiple variants; they differ in the arguments they accept.

__init__(string uri, string prefix, LayoutPkgNamespaces layoutns)   LayoutModelPlugin
__init__(LayoutModelPlugin orig)   LayoutModelPlugin

Each variant is described separately below.


Method variant with the following signature:
LayoutModelPlugin(LayoutModelPlugin orig)

Copy constructor. Creates a copy of this SBase object.


Method variant with the following signature:
LayoutModelPlugin(stringuri, stringprefix, LayoutPkgNamespaces layoutns)

Constructor

def libsbml.LayoutSpeciesReferencePlugin.__init__ (   self,
  args 
)

layout Extension of SpeciesReference.

This method has multiple variants; they differ in the arguments they accept.

__init__(string uri, string prefix, LayoutPkgNamespaces layoutns)   LayoutSpeciesReferencePlugin
__init__(LayoutSpeciesReferencePlugin orig)   LayoutSpeciesReferencePlugin

Each variant is described separately below.


Method variant with the following signature:
LayoutSpeciesReferencePlugin(stringuri, stringprefix, LayoutPkgNamespaces layoutns)

Constructor


Method variant with the following signature:
LayoutSpeciesReferencePlugin(LayoutSpeciesReferencePlugin orig)

Copy constructor. Creates a copy of this SBase object.

def libsbml.ListOfGraphicalObjects.clone (   self)

layout A list of GraphicalObject objects.

The ListOfGraphicalObjects class in libSBML actually represents the ListOfAdditionalGraphicalObjects class in the “layout” package, and is a container for the additional GraphicalObject elements of a Layout.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
GraphicalObject

Creates and returns a deep copy of this ListOfGraphicalObjects.

clone()   ListOfGraphicalObjects
Returns
a (deep) copy of this ListOfGraphicalObjects.
def libsbml.ListOfLineSegments.clone (   self)

layout A list of LineSegment objects.

The ListOfLineSegments is a container for the LineSegment elements of a Curve.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
Input

Creates and returns a deep copy of this ListOfLineSegments.

clone()   ListOfLineSegments
Returns
a (deep) copy of this ListOfLineSegments.
def libsbml.ListOfReferenceGlyphs.clone (   self)

layout A list of ReferenceGlyph objects.

The ListOfReferenceGlyphs is a container for the ReferenceGlyph elements of a GeneralGlyph.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
ReferenceGlyph

Creates and returns a deep copy of this ListOfReferenceGlyphs.

clone()   ListOfReferenceGlyphs
Returns
a (deep) copy of this ListOfReferenceGlyphs.
def libsbml.ListOfSpeciesReferenceGlyphs.clone (   self)

layout A list of SpeciesReferenceGlyph objects.

The ListOfSpeciesReferenceGlyphs is a container for the SpeciesReferenceGlyphs elements of a ReactionGlyph.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
SpeciesReferenceGlyph

Creates and returns a deep copy of this ListOfSpeciesReferenceGlyphs.

clone()   ListOfSpeciesReferenceGlyphs
Returns
a (deep) copy of this ListOfSpeciesReferenceGlyphs.
def libsbml.ListOfCompartmentGlyphs.clone (   self)

layout A list of CompartmentGlyph objects.

The ListOfCompartmentGlyphs is a container for the CompartmentGlyph elements of a Layout.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
CompartmentGlyph

Creates and returns a deep copy of this ListOfCompartmentGlyphs.

clone()   ListOfCompartmentGlyphs
Returns
a (deep) copy of this ListOfCompartmentGlyphs.
def libsbml.ListOfSpeciesGlyphs.clone (   self)

layout A list of SpeciesGlyph objects.

The ListOfSpeciesGlyphs is a container for the SpeciesGlyph elements of a Layout.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
SpeciesGlyph

Creates and returns a deep copy of this ListOfSpeciesGlyphs.

clone()   ListOfSpeciesGlyphs
Returns
a (deep) copy of this ListOfSpeciesGlyphs.
def libsbml.ListOfReactionGlyphs.clone (   self)

layout A list of ReactionGlyph objects.

The ListOfReactionGlyphs is a container for the ReactionGlyph elements of a Layout.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
ReactionGlyph

Creates and returns a deep copy of this ListOfReactionGlyphs.

clone()   ListOfReactionGlyphs
Returns
a (deep) copy of this ListOfReactionGlyphs.
def libsbml.ListOfTextGlyphs.clone (   self)

layout A list of TextGlyph objects.

The ListOfTextGlyphs is a container for the TextGlyph elements of a Layout.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
TextGlyph

Creates and returns a deep copy of this ListOfTextGlyphs.

clone()   ListOfTextGlyphs
Returns
a (deep) copy of this ListOfTextGlyphs.
def libsbml.ListOfLayouts.clone (   self)

layout A list of Layout objects.

The ListOfLayouts is a container for the Layout elements of an extended Model element.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as 'metaid' attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's 'annotation'.

See also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents
Layout

Creates and returns a deep copy of this ListOfLayouts.

clone()   ListOfLayouts
Returns
a (deep) copy of this ListOfLayouts.
def libsbml.LayoutExtension.getPackageName ( )

layout Base extension class for the package.

Returns the nickname of the SBML Level 3 package implemented by this libSBML extension.

getPackageName()   string
Returns
the package nickname, as a string.
Note
Because this is a static method on a class, the Python language interface for libSBML will contain two variants. One will be the expected, normal static method on the class (i.e., a regular methodName), and the other will be a standalone top-level function with the name ClassName_methodName(). This is merely an artifact of how the language interfaces are created in libSBML. The methods are functionally identical.