The items in toolbars may actually be derived from several sorts of instances:
Presenter.Toolbar
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. Normally the choice of configuration is
made by the user in a popup menu on the Main Window.
Users may also configure toolbars on a per-workspace basis,
though currently this is not accessible from the APIs.
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), and also provides a popup menu allowing the user to switch to a different one. To add a new configuration, you should as usual add an instance to the main toolbars folder, which should be a subclass of either:
ToolbarPool.Configuration
(you should implement
this interface according to your needs), which will then be used as
a configuration.
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.