41
edits
Difference between revisions of "Psi Plugins Soc 2006"
Jump to navigation
Jump to search
m
→Finding and displaying plugins
m (→Plugin Ideas: remember to preview before you save.) |
|||
| 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. | ||
====Options Management==== | |||
* 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. | * 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. | ||