openlp/openlp/plugins/plugin.txt
2008-11-17 20:36:01 +00:00

96 lines
2.9 KiB
Plaintext

A plugin architecture for openlp 2.0
------------------------------------
Why?
----
To allow easy development of new "things to display". Examples:
* Bible passages
* Video
* Powerpoint/Openoffice Impress
* Lyrics :) (with chords, rich text, etc...)
* Musical score
* Midi files (hmmm, that's not a thing to display, but feels like it should be there...)
* Audio files, CDs (hmmm again)
* Collections of pictures
* Alerts to members of the congregation
... etc.
The scope of these plugins is "things for display purposes", so
each needs to be able to:
* Render their display (on the projection screen and in a "shrunken form"
for preview purposes)
These plugins need to be part of an OOS. This means they need to
* Be able to tell the OOS manager code what to put in the OOS for their "bit"
* Have a "tab" in the media manager, which they can render on request
to allow bits to be added to the OOS (or indeed shown live)
In addition, some plugins need to be able to show
* How their multiple screens of data are split (eg verses)
* be told which screen to display
Some plugins will also have things to configure, so will need
* to tell the core app that they need a preferences page
* and be able to render it and handle those prefs
Some plugins may need to define
* Hot keys for their display actions. The core will have to pass these on...
Other basic things all plugins will need:
* A name
* A version number
* Helpfile?
Funnily enough, the core lyrics engine fits those requirements, so
could actually form a plugin...
Each OOS entry may be made up of multiple plugins (to do text on
video), so each plugin that contributes to an OOS item will need a
"layering" priority.
Plugin management
-----------------
Plugins will be packages within the plugins/ directory. The plugin
manager will scan this directory when openlp loads for any class which
is based on the base Plugin class (or should we call it the
DisplayPlugin class to allow for other sorts??)
These plugins are then queried for their capabilities/requirements and
spaces made in the prefs UI as required, and in the media manager.
The OOS manager can find out what plugins it has available (we need to
report missing plugins when an OOS is loaded).
The display manager will get a ref to a/some plugin(s) from the OOS
manager when each OOS item is made live, and can then call on each to
render their display.
Each plugin will have basic attributes for
* name
* version number
* capabilities/requirements
(eg:
needs a prefs page,
needs key presses forwarding
has multiple screensful?
)
and a set of API functions for
* media manager rendering and handling
* creating OOS data
* being told OOS data
* set paint context
* render
* selecting a screen to display
* handling preferences
* shortcut key handling...
Other things to add:
Multiple monitors
Openoffice like plugins - external rendering.
update hook for rendering?
Event hook from app
Event hook to app (MIDI events....)