Plugins
From PsiWiki
Contents |
Requirements
Below is a list of requirements for what the plugin API (feel free to add your own or refine these). The mentality for requirements should be "Plugins can do anything and everything".:
- Intercept incoming and outgoing messages, presences, and iqs as well as sending them.
- Add widgets, actions, and be able to do other interesting things with message, chat, and groupchat dialogs
- Configuration option page (or set of pages, need to plan big)
- This can be done via ad-hoc commands between the plugins and Psi proper. I think this is the way to go; have methods in the plugin interface for defining options, and let the plugin interface ad-hoc this. This also has the advantage of allowing outside-client ad-hoc if desired, and making option saving easy.
- Adding actions, contact list menu items, etc. needs to be allowed.
- Add new contact list items and types
- Attaching arbitrary information to roster items (per-contact sound plugin, for example)
Current implementation
Current plugins does use Qt4 plugin classes interface. As whole psi is written in Qt4, it makes sense to use its API if it does have some. It does use Plugin class of Qt. Psi plugins have class PsiPlugin, which is derived from Qt4 Plugin and have QObject inside itself. Current implementation is limited to working with messages and events. It uses interfaces of PluginManager to work with Psi. It does allow plugin to supply QWidget to provide configuring.
Implementing
There will need to be a portable dynamic library class. (I, sneakin, have one that I need to dig up) that can open the library and resolve symbols. A plugin class can then make use of it. Dynamic linking, on linux anyway, seems to be pretty good. Any class inside a program can be used in a dynamic library except templates. So registries and factories will need to be added to some classes, ie: chat dialogs. Iris' stanza classes need to be more extensible or provide access to the raw XML.
The initialization function needs to be defined as a C function, with 'extern "C"'. It can use classes and even return a pointer to an object and take arguments. This will most likely be the Plugin object or whatever we decide.
Wishlist
Trawl the Feature Request forum and in particular the Imaginary Plugins thread.
- A plugin that customizes the icons of wheather transport agents, such that they include the temperature. Probably not the most wanted plugin, but it's just an idea.
- Status scheduling (forum thread: Feature Request: Status Scheduling)
- Spelling check, would want to use a cross-platform, multi-lingual spelling checker such as ispell
- Remote control, using Remko's JEP (JEP-0146 Remote Controlling Clients)
- FServe/DCC style file serving "bot". (See currently deferred JEP-0135 File Sharing)
- User Mood (includes pushing icons onto the roster for existing contacts)
- Auto-Translation
- From Norman -- either do translations in the plugin, or send the text via a translation service. This would cover changing the xml packet being sent to the server
- Nurm's later thoughts: perhaps psi must only have core option to send via translation service, then implement a translation transport - the transport could ask bable to do that translation for it
- A d-bus plugin to allow Linux users (or any platform d-bus runs on) global presence, so psi presence can be exported to any application and vice versa.
- VOIP - Possibly Johnny Talker
- Marcin's VOIP library announched on mailing list, Norman added the wishlist item
- Nurm's later thoughts: looks like Psi might get jingle support in it's core. Still waiting for a win32 library though.
- OTR
Things a plugin might want to access
- Add features to Disco and add Caps Options
- use psi's xmloptions
- handling of adhoc commands
- send popup notifications
- read and set current presence of the users ressources.
- read and manipulate the roaster
- get presence and availible ressources of online contacts
- add elements to outgoing presence messages
- access to psi crypto gpg functions (encryped filetransfers or whatever)
- overriding psi's internal popup / notification implementation (gnome notify framework integration etc)
- registering as sound handler for psi?
- synthesizing messages that psi threads as if they were recived from the server
- some way of extending the message display in the chat dialog?
- manipulate (open, raise, close) MUC and Chat (Dialogs)
- hook into filetransfers?
- LaTeX-Support?
- add things to the roster tooltips
- etc

