Comment 1 by jteh on 2009-02-21 17:06
I assume you mean global scripts.

Mick and i were discussing a plugin mechanism a while ago. Basically, all modules in a plugins folder would be imported and certain code executed. This would allow global scripts to be bound, etc. However, it is important to note that all of these would be loaded at startup. On demand loading is not possible because NVDA has no way to know what scripts it will find in each module without importing it.

Comment 2 by jteh on 2009-05-01 06:52
Changes:
Milestone changed from 0.6 to None

Comment 3 by jteh on 2009-12-08 05:10
Changes:
Changed title from "A way to extend appModules without changes to actual source nor even having it" to "Plug-in mechanism for global scripts"

Comment 4 by aleksey_s on 2010-09-26 06:51
I am researching on it. We might consider using setuptools' entry point mechanism, or implement our own plugin loading. I consider following enterface:

• Each plugin is a subclass of Plugin class which itself is a subclass of ScriptableObject
• they should perform initialization in the constructor and free resources/references in the destructor
• they can react on events by implementing event_xxx methods. To eliminate iterating through whole list of plugins on each event, !PluginLoader will register present event_xxx into list of handlers. Dynamic registering of handlers should be also possible
  Points we still need to think of:
• Does plugin need to be enabled manually by the user or just copying into special location (userConfig/plugins) should do the job?
• What about key to script binding? While we don't have new input framework, may be it is worth-considering to make a .kbd file for each plugin
• What about plugin localization? they should init their gettexts themselves.
• It will be nice if plugin can modify NVDA GUI (adding menu items should be enough). Shall we provide convenient API for it? Another option is to define one standart place for plugin GUI, say a plugin dialog which lists all installed plugins and gives "options..." button for each. Plugin will be called when user presses this button to implement the actual GUI.
• What about API for saving configuration?

Comment 5 by jteh (in reply to comment 4) on 2010-09-29 06:20
Replying to aleksey_s:

We might consider using setuptools' entry point mechanism

Don't know much about that. However, if you think there are advantages to using it, please do tell.

or implement our own plugin loading.

This should be fairly easy if we do it similar to the way we list and load braille display/synth drivers.

• they should perform initialization in the constructor and free resources/references in the destructor

In principle, I agree. However, experience has shown us that a terminate() method tends to be necessary for cleanup, as you can't guarantee when the destructor will be called. For example, you probably want it to be called before we terminate other NVDA components, but you can't guarantee that.

• they can react on events by implementing event_xxx methods. To eliminate iterating through whole list of plugins on each event, !PluginLoader will register present event_xxx into list of handlers.

I assume you mean a map of event names to lists of plugin instances? In practical terms, I'm not sure how much this will actually matter and it does introduce an extra level of complication, but I agree that it's an optimisation worth considering.

• Does plugin need to be enabled manually by the user or just copying into special location (userConfig/plugins) should do the job?

I'd prefer just copy to enable. Simple and reduces confusion.

• What about key to script binding? While we don't have new input framework, may be it is worth-considering to make a .kbd file for each plugin

I think we should probably wait until input framework is done before major work begins on key bindings for plugins.

• What about plugin localization? they should init their gettexts themselves.

Agreed. We'll need to allow plugins to provide locale files.

• It will be nice if plugin can modify NVDA GUI (adding menu items should be enough).

I agree that this is needed, but imo, this ticket should focus on the core framework and other features should be dealt with later. For what it's worth, initially, I think we can just provide access to some core GUI stuff and let people add menu items using wx. We can think about nicer APIs later if they're really necessary.

• What about API for saving configuration?

See above; let's handle this later. However, as food for thought, I guess we could allow a plugin to specify a config spec and config section name.

Comment 6 by jteh on 2010-11-26 07:33
Changes:
Milestone changed from None to 2011.1

Comment 7 by jteh on 2010-11-29 03:15
http://bzr.nvaccess.org/nvda/plugins/

Comment 8 by jteh on 2010-11-29 03:22
In this branch, plugins can bind scripts, receive NVDAObject events and choose NVDAObject overlay classes. However, I'm wondering whether plugins really should receive NVDAObject events after all. Reasons they shouldn't:

• If an event should be handled specially for an object, the plugin should probably do it in an overlay class instead.
  • App modules receive NVDAObject events, but this probably makes more sense because app modules may very well need to do something application wide. Doing something system wide for all NVDAObjects really doesn't make much sense.
• This can only currently be done for NVDAObject events, not tree interceptor events, app module events, etc.
• Performance. We can optimise this (see above), but it's better avoided altogether if there's no good reason to allow this.

Comment 9 by aleksey_s (in reply to comment 8) on 2010-11-29 23:18
Replying to jteh:

However, I'm wondering whether plugins really should receive NVDAObject events after all.

They should; consider making a plugin, which will play a sound icon depending on a state of an object in focus.

Comment 10 by jteh on 2010-11-30 02:35
Merged in 10d7d8a.
Changes:
State: closed