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.

Uh oh!

Plug-in mechanism for global scripts #281

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions