forked from openlp/openlp
96 lines
2.9 KiB
Plaintext
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....)
|