The Real Power of Plugins
I no longer need to use the future tense to discuss what plugins can do. A plugin system is in place presently. Each plugin is a class. Plugins run a register() command to make themselves findable by the plugin system. One registered, they can be loaded. If a plugin allows it, it can even be loaded multiple times. When active, they communicate with signals (not UNIX OS signals, but GlobalSignalDispatcher? signals). Any operation that is performed that multiple plugins might care about is broadcasted. In many cases, the plugins make a call to the core of Hiss, called HissApp?, and it will send a signal to inform other plugins. Plugins can also ask for a function to be called at a later time or even periodically with our generic EventLoop? interface.
At the time of this writing, we have plugins to perform most basic operations. The main one is TkInterface?, which is a child of UIManager?. UIManager? is the framework for constructing user interfaces and abstracts away many of the details for you. Ideally, to create a new UI, all you need to do is explain how things are drawn and let UIManager? handle the logic. There is a Keepalive plugin that sends a keepalive over all connections once per minute. Tk Plugin Loader is a plugin for testing purposes. It lists all plugins and lets you load or unload them. It will ultimately be incorporated into Tk Interface. Tk Raw XML Interface lets you send raw XML to the server, if you're so inclined.
The Power of Plugins (written in 2/2003)
Plugins should be capable of the following (at least):
o Bindings
o Adding menu items
o Adding RMB items for a specific buddy and/or for all buddies
o Add keybindings
- o Bind to any event (though they might not be the first on the callback
- list for it)
- o Filtering (reading and possibly changing) incoming and/or outgoing
- messages. For this, they can register themselves to get all messages, messages of a certain type, message from/to a certain user, etc.
- o Adding new messages to any conversation window, either as system messages
- or actually sending a message to another buddy
- o Basic window manager operations: Raising/minimizing/closing windows,
- changing window focus
o Query which other plugins are active (maybe -- this is under debate)
- o Any other operation that the user can perform. This will come naturally
- if classes are designed logically. We're not too interested in limiting plugins, since many of the primary features of the system (buddy pounces, logging, window autoclosing) will be written as plugins. Hiss itself should have almost no features by itself. The CallbackManager? helps facilitate plugin events.
See also PluginIdeas.