| Trees | Indices | Help |
|
|---|
|
|
Main plug-in management class.
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Inherited from |
|||
|
|||
| [] of class objects |
|
||
|
|||
__metaclass__ = Singleton
|
|||
|
|||
| [] of class objects |
plugins Detected plugin classes. |
||
| [] of GajimPlugin based objects |
active_plugins Instance objects of active plugins. |
||
|
gui_extension_points Registered GUI extension points. |
|||
|
gui_extension_points_handlers Registered handlers of GUI extension points. |
|||
|
|||
|
Inherited from |
|||
|
|||
|
|
|
To Do: what about adding plug-ins that are already added? Module reload |
|
To Do: GUI extension points must be documented well - names with parameters that will be passed to handlers (in plugins). Such documentation must be obeyed both in core and in plugins. This is a loosely coupled approach and is pretty natural in Python. Bug: what if only some handlers are successfully connected? we should revert all those connections that where successfully made. Maybe call 'self._deactivate_plugin()' or sth similar. Looking closer - we only rewrite tuples here. Real check should be made in method that invokes gui_extpoints handlers. |
Removes GUI extension point from collection held by PluginManager. From this point this particular extension point won't be visible to plugins (eg. it won't invoke any handlers when plugin is activated). GUI extension point is removed completely (there is no way to recover it from inside PluginManager). Removal is needed when instance object that given extension point was connect with is destroyed (eg. ChatControl is closed or context menu is hidden). Each PluginManager.gui_extension_point call should have a call of PluginManager.remove_gui_extension_point related to it.
Note: in current implementation different arguments mean different extension points. The same arguments and the same name mean the same extension point. To Do: instead of using argument to identify which extpoint should be removed, maybe add additional 'id' argument - this would work similar hash in Python objects. 'id' would be calculated based on arguments passed or on anything else (even could be constant). This would give core developers (that add new extpoints) more freedom, but is this necessary? |
Adds GUI extension point call to list of calls. This is done only if such call hasn't been added already (same extension point name and same arguments). if they have different name or different arguments.
Note: This is assumption that GUI extension points are different only |
|
|
|
|
|
To Do: success checks should be implemented using exceptions. Such control should also be implemented in deactivation. Exceptions should be shown to user inside popup dialog, so the reason for not activating plugin is known. |
|
|
|
|
Activates all plugins in plugins. Activated plugins are appended to active_plugins list.
|
|
|
|
Note:
currently it only searches for plugin classes in '*.py' files
present in given direcotory
|
|
|||
__metaclass__
|
|
|||
pluginsDetected plugin classes. Each class object in list is GajimPlugin subclass.
|
active_pluginsInstance objects of active plugins. These are object instances of classes held plugins, but only those that were activated.
|
gui_extension_pointsRegistered GUI extension points. |
gui_extension_points_handlersRegistered handlers of GUI extension points. |
| Trees | Indices | Help |
|
|---|
| Generated by Epydoc 3.0.1 on Thu Aug 12 02:07:14 2010 | http://epydoc.sourceforge.net |