Every plugin needs to implement the
xnap.plugin.Plugin interface. As
a convenience xnap.plugin.AbstractPlugin
is provided. It already contains methods to handle the
PluginInfo object. The
PluginInfo object is used to store
information about the plugin and is created by the
PluginManager. I will explain how to use
that in a later chapter. We will now go on and create the plugin
class.
I created a package named xnap.plugin.jtella. Most of the core
plugins are located beneath the xnap.plugin package, but would
not need to be. I will call the plugin class
JtellaPlugin. This is easy to remember
and most of XNap's plugin classes are named like that.
When the plugin is enabled the plugin manager will at first
invoke start(). If the gui is visible
startGUI() will be invoked once
start() returns. XNap has a command line
mode that provides a few basic commands. Of course plugins can
provide their own commands as well. I will use
start() to initialize the jtella core but
not connect the network, yet.
In order to connect to another gnutella servant we will need a
host and port. Therefore I will implement a simple panel with
text fields and a few buttons. The panel class is called
JTellaPanel and extends
JPanel.
XNap provides a class for validated input fields called
ValidatedTextField. I will use that for
the port text field. Another cool class is the
GridBagHelper. It contains a set of
static methods that ease the use of the tedious
GridBagLayouts greatly. The
GridBagHelper also makes sure that all
components throughout XNap use the same insets which makes the
application look uniform.
To handle the button I will use an inner class
Action called
AddServantAction. Actions are a nice way
to abstract the action that is performed from the widget that is
triggering the action. Java's action concept is not yet as good
as it could be though, it lacks support for
ToggleAction and differently sized icons.
We love icons. They make applications look sexy. But icons need
to have certain sizes to integrate nicely with the displaying
components. Therefore XNap's framework contains replacement
classes for the most common components like menus and
buttons. These components take an Action
object in their constructor and read a special property
IconHelper.XNAP_ICON
that contains the icon's filename. XNap's icon path is searched
for an appropriate sized icon, if none can be found a bigger one
is scalled down, much like the KDE icon framework.
To make use of XNap's main tool bar we need to provide Action
objects that will be added to the tool bar once our panel gets
the focus. The ActionProvider interface requires to implement a
getAction() method that returns an array of
Action objects. We only need to implement
that interface, XNapFrame will take care
of the rest.
Right, defining a class is not enough. We need to add it to the
application frame. That class is called
XNapFrame and provides useful hooks to
add panels. We will call the
XNapFrame.insertTab method from our
plugin class.