Mesquite is built of modules. Each module has one particular sort of job to do (such as calculate a value for a tree); many job categories will have many modules available to perform those duties. Combined these modules provide all of the work teams that can accomplish a particular task. A basic installation of Mesquite has over 900 modules, and with additional packages of modules installed, the number can be well over 1000. To see all currently installed modules, choose Help>Show Web Page of All Modules.

You can use Mesquite perfectly well without paying any attention to its modularity or how the modules work. But knowing how the modularity functions will give you significantly more power and flexibility in using Mesquite, and it will allow you to be able to more quickly figure out how to accomplish tasks. An understanding of the modular system will help the user more effectively give commands to Mesquite via menus and scripting, and interpret the results obtained.

The page on how Mesquite works introduces modules and how they cooperate. In brief, modules link together to perform calculations and display the results to the user. The linkage of modules is in the form of a tree, with the root module being the "trunk" Mesquite module itself. Which modules are currently active depends on the files the program has read and the calculations the user has requested.

Installed versus loaded versus running modules

An installed module is one available to be used: it is sitting as a file or a series of files on your disk or web server. Mesquite can find these modules and, if approprate, can get them started up. Among the installed modules might be some that you never use, because you don't happen to need their calculations.
Not all installed modules are available to a user during a Mesquite run. The reason is that, although a module might be physically installed, it might not be loaded by Mesquite at startup. An installed module might not be loaded if, for instance, the user has chosen a configuration to control the loaded packages (see Activate/Deactivate Packages in the File manue). The configuration file might indicate that only some of the packages are to be loaded and available.
When Mesquite starts up, or when the user requests new windows, calculations, and so on, some of the loaded modules are started up to do the work. These are the running modules.

This characterization is a bit misleading, however, since many active copies of a single module on disk can be running at once. That is, the installed module on disk can be thought of as a blueprint for a machine, and each time Mesquite needs to start up a module, the machine is built and started. If Mesquite needs another machine of the same sort, it can build a new one from the blueprint. Many machines (running modules) from a single blueprint (loaded module) can be built and be running simultaneously.

(To the programmer, the loaded modules are the available classes that are subclasses of the basic module class; an active module is an object instantiated from one of these classes.)

Where modules are installed

To be installed and found by the Mesquite system, a module must be within one of four places. We will describe each under the assumption that a package "mypackage" with a single module "MyModule" is being installed.
  • the mesquite directory of Mesquite_Folder: this is the primary location for modules. This is the only location modules can be located for use on Mac OS 9. If installed here, our example module would be at: Mesquite_Folder/mesquite/mypackage/MyModule/MyModule.class
  • in Mesquite_Folder/additionalMesquiteModules/mesquite: this is an optional location for modules. If you are installing 3rd party modules, you might want to install them here, so that you can easily find them again and reinstall them when you upgrade to a newer version of Mesquite. If installed here, our example module would be at: Mesquite_Folder/additionalMesquiteModules/mesquite/mypackage/MyModule/MyModule.class
  • in Mesquite_Support_Files/classes/mesquite: this is an optional location for modules. It can be useful for users who don't have permission to modify the main Mesquite_Folder but may want to install new modules. If installed here, our example module would be at: Mesquite_Support_Files/classes/mesquite/mypackage/MyModule/MyModule.class
  • at the locations specified in a text file. In Mesquite 3.4 and later, this should be a simple text file called classpaths.txt that is in Mesquite_Folder (i.e., Mesquite_Folder/classpaths.txt). In Mesquite 3.31 and earlier it is in an XML file Mesquite_Folder/classpaths.xml. The simple text file for 3.4 and later should have a format as follows:
    • ../MyExtraModules
    • ../MoreExtraModules
    To disable a path, put a number/pound symbol (#) in front of it.
    The format for the XML file for Mesquite 3.31 and earlier is:
    • <?xml version="1.0"?>
    • <mesquite>
      • <classpath>../MyExtraModules</classpath>
    • </mesquite>
    This tells Mesquite to look outside of Mesquite_Folder, and inside MyExtraModules for the root of the classpath. If installed here, our example module would be at: MyExtraModules/mesquite/mypackage/MyModule/MyModule.class.

Furthermore, the active configuration must specify that the module's package be loaded. By default, all installed packages are loaded.

Thus, if you open up the Mesquite_Folder, you might see the following
  • com
  • corejava
  • documentation.html
  • edu
  • examples
  • images
  • lesser.txt
  • pal
  • mesquite. In this directory, you might see:
    • ancstates
    • assoc
    • basic
    • batchArch
    • categ
    • charMatrices
    • charts
    • coalesce
    • configs
    • cont
    • distance
    • genesis
    • io
    • jama
    • jsci
    • lib
    • lists
    • Mesquite.class
    • minimal
    • molec
    • ornamental
    • pairwise
    • pal
    • parsimony
    • rhetenor
    • search
    • stochchar
    • treefarm
    • trees
    • trunk
Each of the items in bold above is a directory (folder) that contains modules. Within minimal, you might see:
    • BasicFileCoordinator
    • Defaults
    • DrawHierarchy
    • InterpretNEXUS
    • ManageForeignBlocks
    • (and so on)
Each of these directories is for one module. For a module to be found and used by Mesquite, it must be present in a directory whose name is the same as the class file for the module (e.g., the class file for the module "Basic File Coordinator", BasicFileCoordinator.class, must be in a directory named BasicFileCoordinator).

Modules currently in use

While Mesquite is running you may want to learn what modules are currently running. In the Help menu the Active Module Tree menu item displays a window that displays the modules currently running. You can also see the modules responsible for any window by selecting the menu item Window>View Mode>Modules.

If you touch on the name of the module in theses module tree displays, a menu will drop down that allows you to find out information about the module.

Information pages and Manuals for modules

Mesquite gathers information about each module and summarizes it in an information page for each module. These are linked from the page available via the Modules Loaded menu item in theHelp menu while Mesquite is running. As well, some individual modules have their own manuals in the form of web pages. These are also linked from the Modules Loaded web page.