41
edits
Difference between revisions of "Psi Plugins Soc 2006"
Jump to navigation
Jump to search
Next update
m (→Plugins) |
(Next update) |
||
| Line 14: | Line 14: | ||
* Directory watching has been implemented on the plugin directories, such that new plugins will be located as soon as they're installed | * Directory watching has been implemented on the plugin directories, such that new plugins will be located as soon as they're installed | ||
* I've written plugin loading and unloading code. On Windows and Linux this means that plugins can be loaded and unloaded on the fly (allowing plugin upgrading while Psi is running). On OSX it's not possible to unload the .dylib once it's loaded and the code works around this, allowing plugins to be disabled but not unloaded, with the objects cached so they can be re-enabled later without a restart. | * I've written plugin loading and unloading code. On Windows and Linux this means that plugins can be loaded and unloaded on the fly (allowing plugin upgrading while Psi is running). On OSX it's not possible to unload the .dylib once it's loaded and the code works around this, allowing plugins to be disabled but not unloaded, with the objects cached so they can be re-enabled later without a restart. | ||
* I've written a large chunk of a generic (non-Psi dependent) soft-coded options structure. What this means is that you can use options dynamically by just calling something like <code>options.setOption("path.to.option",true)</code> and the value will be stored in the tree, regardless of whether the options tree was expecting you to have an option named "path.to.option" or not. This is then dumped to xml for storage on disc, and the xml parsed back in to recreate the tree. It's also possible to store comments for each node or value, this is useful both for the xml to be readable and for writing a generic options dialog, which allows you to edit any value stored in the tree, without knowing in advance what these are. | |||
==Tasks== | ==Tasks== | ||
| Line 43: | Line 44: | ||
| Display plugin's own options in OptionDlg | | Display plugin's own options in OptionDlg | ||
| 20% | | 20% | ||
|- | |||
| Write a soft-coded options structure, such that we don't need to know what options we have in advance (and also allow us to remember options we don't know about, such as when running without plugins) | |||
| 75% | |||
|- | |- | ||
| Allow plugins to store their options in PluginManager (options[], with an options.addComment()) | | Allow plugins to store their options in PluginManager (options[], with an options.addComment()) | ||
| 0% | | 0% | ||
|- | |- | ||
| Line 102: | Line 103: | ||
* Python Scripting Plugin | * Python Scripting Plugin | ||
** This one's pretty crucial to the project | ** This one's pretty crucial to the project | ||
* URL watcher | |||
** As [http://missig.org/julian/blog/2006/05/29/idea-im-link-history/ | Julian suggested], it would be nice for clients to keep a log of URLs sent to you which you can visit later, much like many IRC users enjoy. | |||
===Script Ideas=== | ===Script Ideas=== | ||