# Actions API - Advanced Toolbar Configuration

The items in toolbars may actually be derived from several sorts of instances:

1. An action implementing `Presenter.Toolbar`
2. Any `Component`. Usually this will just be a `JToolBar.Separator`, since special widgets such as combo boxes and so on are better given as the toolbar presenter of an action.

A toolbar as created when a folder is encountered is actually an instance of `Toolbar`, which is a subclass of `JToolBar` that is able to compose itself from the contents of a folder. If you want to replace the whole toolbar with a special component, you may do so. You need only provide an instance of some subclass of `Component` (in the main toolbars folder) rather than a subfolder.

All available toolbars, whether created by the normal folder-scanning mechanism or whether custom written, are available using `ToolbarPool.getToolbars()`. However, at any given time not all of these are visible. All of this information is controlled by a `ToolbarPool.Configuration` object. All available configurations are listed in `ToolbarPool.getConfigurations()`, and `ToolbarPool` also permits the current configuration to be retrieved and set. Please note that even though there are two ToolbarConfiguration instances by default (Standard/Coding and Debugging) there is no user interface for switching between them. Use `ToolbarPool.setConfiguration(String)` to activate a different toolbar configuration. Users may only show/hide toolbars from the active configuration.

What are these configurations and how may new ones be added? Essentially, a configuration is just a component which displays the toolbars it represents (it is the responsibility of the configuration to determine which these are). To add a new configuration, you should as usual add an instance to the main toolbars folder, which should be a subclass of either:

1. `ToolbarPool.Configuration` (you should implement this interface according to your needs), which will then be used as a configuration.
2. `Component` (but not `JToolBar`), in which case the supplied component will be wrapped in an adapter which provides the name and a standard popup menu, while the display is otherwise handled by the component.

Currently, the standard toolbar configurations are a private implementation of `ToolbarPool.Configuration` which reads the configuration based on an XML file. The format of this file is not specified by the Open APIs, so modules should not attempt to modify it. (A user-level customizer for such files may be supplied.) Rather, module authors should note that the standard implementation lists toolbars from the pool which should be displayed, and possibly also toolbars which should not be displayed; any toolbar in the pool not explicitly mentioned will just be displayed somewhere at the end of the component. So, module-supplied toolbars will at least appear, though their exact placing will not be customizable.