General Modularity Example Module Projects & Files Commands & Scripting Windows Menus Charts Tables Buttons & tools Trees and Taxa Characters & Models Documentation General Utilities Table of Contents Overview To Do: issues and problems Home page of user's manual User's introduction to how Mesquite works Classes and Interfaces (javadoc output)

Overview of Mesquite development

W. Maddison (updated May 2006)

Mesquite consists of class libraries that define the basic architecture, and modules that perform calculations and report the results to the user. It is written in Java. The page on source code also includes a description of how to prepare an Eclipse workspace for Mesquite development.

Modularity is an inescapable theme with Mesquite. Data, analyses, windows, menus, and other aspects of Mesquite are all under the control of a team of cooperating modules. Because the set of modules installed and in use at any one time may vary, many aspects of Mesquite from available options to menu structure to documentation cannot be fixed, but depend on what modules are involved. This allows for great flexibility, but puts challenges on the architecture of the system for which the developer should be prepared. For a basic introduction to Mesquite's modular architecture, see how Mesquite works. For a more in-depth presentation for developers, see the page on Mesquite's modular architecture.

In general, the easiest way to write modules is to find a module that does an analogous task, copy the code and modify it.

Some of the notable features of the Mesquite system are:

• Modules: are subclasses of MesquiteModule (javadoc version). They are not simply "plugins" that attach individually to some large mother program. Rather, the modules cooperate with each other, like building blocks, to perform tasks. New modules can contribute entirely new (and unanticipated) functions to Mesquite. Active modules are linked to one another in the form of a tree, with the Mesquite trunk module acting as the root to initiate Mesquite. Modules hire other modules to perform tasks, and thus the tree represents (in a sense) a corporate hierarchy.
• Interchangeable parts: Modules are grouped by "duties" that they promise to perform, and in many calculations different modules can be used to perform the same duty, with different results. Thus, many different modules can produce a number for a tree, and by employing different ones of these modules, a chart can display many different results. For a basic introduction to duties, see how Mesquite works.
• Scripting: Many of the user-interface commands in Mesquite use, internally, a scripting language. This scripting language is accessible to users who can write scripts to run Mesquite automatically via the Puppeteer class. For an introduction as to how to script Mesquite, see the user's guide to scripting. The same scripting system is used by Mesquite in saving files and cloning windows (modules and windows can return Snapshots of the scripting commands needed to return them to their current state).
• Auto-documentation: the methods of the CommandChecker class help to build documentation of commands, modules, menus and controls while Mesquite is running. This not only gives the user an up-to-date and pertinent manual for the system as it stands at the moment, but also allows developers to embed much of their documentation within the source code of the modules.