Version 5 (modified by ebmoore, 13 years ago) (diff)


Package Overview

While there are many packages in MindSeer, there is a method to the madness. To begin with, a good deal of the structure is designed to eliminate circular dependencies. Also things are split up so that some packages could be broken off with relatively little work for use in other projects.


Packages in this hierarchy are owned by the University of Washington and the long name follows Java guidelines. This also includes 3 classes. These classes handle creating and managing objects with unique ids across communicating platforms. This is also where the base class for SynchronizationObserver? lives.


These files are what make up MindSeer.


Colors contain classes related to color schemes (which assign colors to intensity values) and some utilities (class Colors) for converting strings to colors and back again.


These are custom SwingHTMLObjects and collections. They are in a separate package because they are compiled into the Client version.


The core comprises the central classes for ensuring that MindSeer works. These include most communication links, the client UI, the Viewport, MindSeer specific Data Set classes (the generic classes are in the vault package) and the security protocol.


This includes the Client Manager (which manages communication and acts as a central hub), the callback mechanism, and the client UI (the menus and the base class for Layout Managers).


These are client specific user interface items like the Splash Screen during login and the popup to save data.


Concrete implementations of Layout Managers and helper files live here.


These classes extract user displayable names for objects in trees and lists.


Files contain the MindSeer specific data set details. These refer to the Data Set as a Workspace and include details on creating a tree for the data set.

The security files contain the details on establishing and enforcing permissions for users and groups. This delves heavily into the Java security model. Most of these are package private for security purposes.


These classes include details on communication with the client, launching the server itself and such important classes as the SessionImpl? and Viewport.


This package deals with Data objects, Encoders and Decoder, the Data Manager, Data Views, Data Models (collections of Data), keys for data and other helper classes and default implementations of interfaces.


This is a bit of a catch all for Data Controllers (see interface DataController?).


In order to implement undo/redo, many commands needed to be encapsulated into using the Command Design Pattern. They are encapsulated into objects that implement DoCommand?. Two main kinds of command objects exist -- state targeted and invertible. State targeted commands encapsulate the current and previous state of the target. Invertible commands store how to change the view and how to undo what they did. These are then fired at a Do Target (which Viewport later implements), which is in charge of managing the appropriate thread and ensuring efficient execution.

This packages is probably a bit too generic for its own good as it became complex enough to make incorporating into external programs difficult, but is probably manageable if the Controllers are moved into a different package.


These are supposed to be classes that ease the problem of developing plugins. Currently only Helper and LongTask? are useful and Helper has many unimplemented methods.


These are all sorts of helpful icons (they implement Icon) for displaying things in a Swing UI. They are compiled into the client. Many of these would probably be useful in other programs.


This holds the details for decoding and encoding images into MindSeer and creating Data objects for them.

This is a very good place to look for examples on implementing Encoders, Decoders and Data objects.


This holds the details for decoding and encoding maps into MindSeer and creating Data objects for them. Maps have locations and attributes.


This includes all of the details for loading, saving and generating data for 3D surfaces. It also includes some helper classes for a 3D scene and the Surface Data Model handles aa lotlot of Java3D details. Objects need to implement Surface3DView to be displayable in a Surface Data Model.


Peter developed a plugin for text files in order to learn the system.


In here are contained almost all of the information for synchronizing client and server by using observers.


This package exists to eliminate circular dependencies. It contains a single interface that encapsulates details on units and transforms. The feature that this exposes (changing units and converting objects between coordinate systems on the fly) was never fully implemented.


These are mostly wrapper classes for swing objects and data models to create a transparent client/server system.


These are the GUI events used by shwing classes.


These are custom swing objects that are used by shwing classes to display themselves in swing.


Util contains an eclectic collection of helper classes, and you will need to look at the javadoc. Of note in here are the observerables package and the RemoteImage?* classes for shipping images from the server to the client.


These are classes to help with files, most deal with the custom file chooser that can handle client / server.


This is a very important set of classes for collections that implement the observer pattern so that changes may be watched. These classes are central to semi transparent client-server.

Use ObserverableCollections? to create observable collections.


These are a set of simple viewports that don't deserve their own package. They include the Image Viewport and the Map Viewport.


This package has the Model 3D Viewport as well as all of the Data Views that are supported by the Model 3D Viewport. It also contains Viewport Controllers and Peter's code.


This package has the Volume Viewport as well as all of the Data Views that are supported by the Volume Viewport. It also contains Viewport Controllers and helper classes.


This contains the Data objects (Volume Data), file types, encoders and decoders as well as several helper classes.


These classes deal with converting volumes to surfaces (right now just isosurface extraction).


The vault classes were originally conceived as a library for metadata about files. It is not known if this library could be used externally from MindSeer. It contains most of the MindSeer independent logic for displaying, querying and building a data set. The original design was a little ambitious and so users can create alternate backing stores using databases or basic maps.


These are the central classes for creating nodes, associating meta data and creating collections (DataVault?) of files with metadata. It also contains classes to execute queries.


This includes classes for displaying and rearranging trees in Swing.


These classes include filters for file types and utilities for files.


These classes were supposed to handle synchronization of the vault. They are not used or tested.


The xml package contains classes to convert a Data Vault to or from XML.


Generic NIFTI classes live here. They can be used as an external library for reading NIFTI files. Because it also handles SPM's transform, this library depends on matfile.


These classes are responsible for reading a Matlab version 4 or 5 file and converting it into Java objects. They are a separate library from MindSeer.


Packages in this hierarchy are copyrighted by Eider Moore. They were from his personal library and released under the LGPL.