Skip to content


Subversion checkout URL

You can clone with
Download ZIP

Plugins API

Frank Duncan edited this page · 11 revisions

(The information contained in this page dates back to early 2012. Consider it to be pretty dated. NetLogo plugins have generally been shunned as unnecessarily-powerful super-extensions, and you are encouraged to just use extensions whenever possible. However, some good uses of the Plugins API include 6.x and CRESS'/Surrey's eXtraWidgets plugin.)

The plugins API is new and totally unofficial and experimental, etc. We intend to maintain and improve it, but we're not promising anything yet.

For now, the documentation that follows is skeletal.

Purpose and design

Currently the plugins API lets you add a new tab to NetLogo, alongside the existing Interface/Info/Code tabs.

We plan to expand the API to also allow adding menus, menu items (e.g. on the Tools menu), primitives, etc.

Ideally the API would be complete enough that features like BehaviorSpace, HubNet, and others would become plugins, rather than being part of the main codebase. (If a plugin was bundled with NetLogo, then users wouldn't notice that anything changed.)

There shouldn't be/aren't any bounds on plugins, any more than there are bounds on what applications you can embed NetLogo in. The so-called "API" is hardly there at all, it's paper-thin and basically just lets you add a tab that does something totally arbitrary. It's not like the extensions API. There is no layer of abstraction insulating you from the rest of NetLogo. Extensions can bypass that layer anyway, but for plugins, such a layer doesn't even exist.

Example plugins is a small sample plugin written in Java.

Another example is, written in Scala. (This particular plugin requires the abmplus branch of NetLogo to run.)

Writing a plugin

To make a plugin, you subclass java.awt.Component. Typically you will want to subclass something more specific, for example javax.swing.JPanel.

The constructor may take no arguments, or any arguments that PicoContainer can inject from the app.App context. For example, a typical constructor might take a org.nlogo.window.GUIWorkspace argument, which PicoContainer knows how to inject.

Scala example:

class ReviewTab(workspace: GUIWorkspace) extends JPanel { ... }

Java example:

public class ReviewTab extends JPanel {
  public ReviewTab(GUIWorkspace workspace) { ... } }

Building and running

Compile your class and make a jar with a manifest with lines like:

NetLogo-API-Version: 5.0
Tab-Name: Review

and then put it with the NetLogo directory at e.g. plugins/ReviewTab/ReviewTab.jar. The ReviewTab directory can have arbitrary other stuff in it as well (e.g., the source code, so you can do the development in-place).

The .jar file must have the same name as the Tab, and it must be in a directory with that name as well. (In this example, the directory is called ReviewTab and the jar is named ReviewTab.jar.)

Source code

This is invoked from app.App.finishStartup(), which does:

    tabs.init(Plugins.load(pico): _*)
Something went wrong with that request. Please try again.