This page describes the basics of how to develop custom applications using the toolkit. It will introduce you to the key concepts and classes that you should be familiar with in order to begin writting applications. Reading this section you will hopefully come away with an understanding of the core layers and components of the toolkit and how they are meant to fit together to build applications.

For documentation on installing the binaries, please refer to the Binary Installation Guide.

This toolkit is divided into a number of packages which logically partition the classes into functional areas. It also helps to simplify where to find different components when it comes time to choosing classes to use within applications. Furthermore, the packages provide a means to identify the desired level of functionality needed for a particular application. For example, if an application is to provide no graphical user interface (eg: for a server-side library component or a command line tool) then it is likely that you will only need to use the core data model classes (package edu.sdsc.mbt) and the i/o components to read data (package edu.sdsc.mbt.io). You are in no way required to import or use every package to build useful tools using this toolkit.

Packages

In order to begin providing a sense for what general capabilities that the toolkit provides, a brief overview of each package will help establish a "map" of the system to set the context as we progress through describing the details of the toolkit:

edu.sdsc.mbt	This package provides classes which define the core data storage containers for the MBT toolkit.
edu.sdsc.mbt.filters	This package provides classes which enable filtering or subsetting of a structure's constituent components.
edu.sdsc.mbt.gui	This package provides classes which implement graphical user interface (GUI) component classes for MBT.
edu.sdsc.mbt.io	This package provides classes which enable molecular biology data sets (such as protein structures, sequence data, etc) to be loaded into an MBT application as a Structure object.
edu.sdsc.mbt.util	This package provides classes which implement extra functionality on top of the core MBT classes (that is, capabilities that are not absolutely required by, or would otherwise overcomplicate, the core classes).
edu.sdsc.mbt.viewables	This package provides classes which enable molecular biology data to be represented as visible/renderable viewable objects, plus, this package defines a top-level StructureDocument object to encapsulate the complete state of these objects and properties.
edu.sdsc.mbt.viewers	This package provides classes which enable data to be graphically visualized or to be processed by other means based upon coordinated events (that is, any MBT component that wishes to observe data and then respond and interact to changes in that data).

Architecture

While any given application may use a subset of packages and classes from the toolkit, it is useful to present a map of how a more full-featured application might be built from many components in order provide a picture of how the key software components are designed to work together. The following diagram provides a "30,000 foot view" of how the major components are meant to be used together. The diagram hopefully also reinforces what functionality is gained from each package of the toolkit:

Starting from the bottom (ie: from Data) working up through to the top level (ie: the Application), you begin to see how some of the core components are meant to fit together and interoperate within the context of a complete application. Most applications will need to load data from one or more sources. The application then needs a way to access and walk through the data. Often, there is data that is not always part of the data set itself, but there is data that needs to be algorithmically derived (eg: bonds, secondary structure, etc). Finally, applications that wish to display a visual representation of the data often need a way to map viewable attributes (like color, size, form, and visibility) in a consistant manner. Finally, some physical widgets or viewers that display renderings of the data may be needed.

Lets start at the bottom of this architecture map and examine the actual packages and classes which applications will use to accomplish these layers of functionality.