|
38 | 38 | * What all plugins have in common is that they are declared using an annotation |
39 | 39 | * (@{@link Plugin}), and discovered if present on the classpath at runtime. |
40 | 40 | * </p> |
| 41 | + * <p> |
| 42 | + * The core types of plugins are as follows: |
| 43 | + * </p> |
| 44 | + * <ul> |
| 45 | + * <li>{@link org.scijava.command.Command} - plugins that are executable. These |
| 46 | + * plugins typically perform a discrete operation, and are accessible via the |
| 47 | + * application menus.</li> |
| 48 | + * <li>{@link org.scijava.display.Display} - plugins that visualize objects, |
| 49 | + * often used to display module outputs.</li> |
| 50 | + * <li>{@link org.scijava.module.process.PreprocessorPlugin} - plugins that |
| 51 | + * perform preprocessing on modules. A preprocessor plugin is a discoverable |
| 52 | + * {@link org.scijava.module.process.ModulePreprocessor}.</li> |
| 53 | + * <li>{@link org.scijava.module.process.PostprocessorPlugin} - plugins that |
| 54 | + * perform postprocessing on modules. A |
| 55 | + * {@link org.scijava.module.process.PostprocessorPlugin} is a discoverable |
| 56 | + * {@link org.scijava.module.process.ModulePostprocessor}.</li> |
| 57 | + * <li>{@link org.scijava.platform.Platform} - plugins for defining |
| 58 | + * platform-specific behavior.</li> |
| 59 | + * <li>{@link org.scijava.service.Service} - plugins that define new API in a |
| 60 | + * particular area.</li> |
| 61 | + * <li>{@link org.scijava.tool.Tool} - plugins that map user input (e.g., |
| 62 | + * keyboard and mouse actions) to behavior. They are usually rendered as icons |
| 63 | + * in the application toolbar.</li> |
| 64 | + * <li>{@link org.scijava.widget.InputWidget} - plugins that render UI widgets |
| 65 | + * for the {@link org.scijava.widget.InputHarvester} preprocessor.</li> |
| 66 | + * </ul> |
41 | 67 | * |
42 | 68 | * @author Curtis Rueden |
43 | 69 | * @see Plugin |
|
0 commit comments