Installing a plugin simply places it in the user's plugins directory (~/.drpython/plugins), which are added to the module load path.
(or c:/Documents and Settings/Username/drpython/plugins
Installed plugins are loaded upon install, and also
on startup.
Uninstall removes them from the plugins directory,
and executes cleanup code written by the plugin author.
Plugins
will simply be loaded as a module.
plugin writes can use wx.Menu.Insert() to add their items
to the menu, and I will write code to allow a plugin
to add itself to the right click menu, and to shortcuts.
All plugins will be loaded at the end of the __init__() section of the main DrFrame.
This will allow them to access specific menus, preferences, etc.
Another option might be to classify plugins.
For example, let the user create subdirectories of plugins,
that are not loaded by default:
The directory (~/.drpython/plugins/Zope) would exist, with, let's say, five
plugins. When the user selects "Load ... Zope", all of these plugins
are then loaded into DrPython. This way you can load classes
of plugins on startup, and load some only when you are working on
specific projects.
I would also have to make a way for plugin designers to "package"
a set of plugins they wrote, and allow users to make their own
packages of plugins (a package simply being a subdirectory containing
the plugins to be loaded).
Also, this would be a cool thing to work into the project manager.
Allow certain packages of plugins to be loaded with specific projects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let's get this party started.
Here is what I am thinking:
Options
Plugins
Install
Uninstall
Installing a plugin simply places it in the user's plugins directory (~/.drpython/plugins), which are added to the module load path.
(or c:/Documents and Settings/Username/drpython/plugins
Installed plugins are loaded upon install, and also
on startup.
Uninstall removes them from the plugins directory,
and executes cleanup code written by the plugin author.
Plugins
will simply be loaded as a module.
plugin writes can use wx.Menu.Insert() to add their items
to the menu, and I will write code to allow a plugin
to add itself to the right click menu, and to shortcuts.
All plugins will be loaded at the end of the __init__() section of the main DrFrame.
This will allow them to access specific menus, preferences, etc.
Another option might be to classify plugins.
For example, let the user create subdirectories of plugins,
that are not loaded by default:
Options
Plugins
Load
Graphics
Zope
Install
Uninstall
The directory (~/.drpython/plugins/Zope) would exist, with, let's say, five
plugins. When the user selects "Load ... Zope", all of these plugins
are then loaded into DrPython. This way you can load classes
of plugins on startup, and load some only when you are working on
specific projects.
I would also have to make a way for plugin designers to "package"
a set of plugins they wrote, and allow users to make their own
packages of plugins (a package simply being a subdirectory containing
the plugins to be loaded).
Also, this would be a cool thing to work into the project manager.
Allow certain packages of plugins to be loaded with specific projects.
I think plugin packages should be implemented as index files:
~/.drpython/plugins/modules
~/.drpython/plugins/config
~/.drpython/plugins/startup.dpp
config will include package files
(.dpp) drpython plugin package, which specifies
which modules to load.
modules will include the .py files.
startup.dpp will list the modules
loaded on startup.