diff options
| author | Klaus Schmidinger <kls (at) cadsoft (dot) de> | 2002-06-16 18:00:00 +0200 |
|---|---|---|
| committer | Klaus Schmidinger <kls (at) cadsoft (dot) de> | 2002-06-16 18:00:00 +0200 |
| commit | f06d2c27fca449148d9d8fac19d81c668744f170 (patch) | |
| tree | 8f21a604339719672bf7ab8b6e9d69bfa1817ac5 /PLUGINS.html | |
| parent | d07e3829f7c44d713b2677ef73f864af80b3dea3 (diff) | |
| download | vdr-patch-lnbsharing-f06d2c27fca449148d9d8fac19d81c668744f170.tar.gz vdr-patch-lnbsharing-f06d2c27fca449148d9d8fac19d81c668744f170.tar.bz2 | |
Version 1.1.3vdr-1.1.3
- Improved the VDR Makefile to avoid a warning if the '.dependencies' file does
not exist, and also using $(MAKE) to call recursive makes.
- Changed the name of the 'package' target in the plugin Makefiles to 'dist'
(following the suggestions in the "GNU Make" manual). If you already have started
a plugin project, you may want to change this in your Makefile accordingly.
- Improved the plugin Makefile to avoid a warning if the '.dependencies' file does
not exist, and also using $(shell...) to get the version numbers. If you already have
started a plugin project, you may want to change this in your Makefile accordingly.
- Fixed some function headers to make them compile with gcc 3.x (thanks to
Gregoire Favre).
- Fixed the cutting mechanism to make it re-sync in case a frame is larger than the
buffer (thanks to Sven Grothklags).
- Added an error message if the directory specified in the '-L' option can't be
accessed (suggested by Stefan Huelswitt).
- Rearranged OSD class names to make 'cOsd' available for the main OSD interface.
- Completely moved OSD handling out of the cDvbApi class, into the new cOsd.
- Implemented cStatus to allow plugins to set up a status monitor.
See PLUGINS.html for details.
- Moved the cEITScanner out of dvbapi.h/.c, into the new eitscan.h/.c.
- Added Swedish language texts (thanks to Tomas Prybil).
- Fixed parsing 'E' records in epg2html.pl (thanks to Matthias Fechner for pointing
out this one).
- Removed compiler option '-m486' to make it work on non-Intel platforms. If you
have already started a plugin project, you may want to make sure you remove this
option from your existing Makefile.
- Completely rearranged the recording and replay functions to make them available
to plugins.
- Replay is now done in a single thread (no more syncing between input and output
thread necessary).
- It is now possible to record several channels on the same transponder with "budget
cards". VDR automatically attaches a recording timer to a card that already
records on the appropriate transponder. How many parallel recordings can actually
be done depends on the computer's performance. Currently any number of recordings
gets attached to a card, so you should carefully plan your timers to not exceed
the limit. On a K6-II/450 it was possible to record three channels from transponder
12480 with a single WinTV NOVA-S.
- Timers that record two successive shows on the same channel may now overlap and
will use the same DVB card. During the time where both timers record the data
is simply saved to both files.
- The following limitations apply to this version:
+ Transfer mode doesn't work yet.
+ The '-a' option (for Dolby Digital audio) doesn't work yet.
+ Switching between different language tracks doesn't work yet.
+ Cutting doesn't work yet.
Diffstat (limited to 'PLUGINS.html')
| -rw-r--r-- | PLUGINS.html | 125 |
1 files changed, 108 insertions, 17 deletions
diff --git a/PLUGINS.html b/PLUGINS.html index 4cc27da..9b5a496 100644 --- a/PLUGINS.html +++ b/PLUGINS.html @@ -4,7 +4,7 @@ </head> <body bgcolor="white"> -<h1>The VDR Plugin System</h1> +<center><h1>The VDR Plugin System</h1></center> VDR provides an easy to use plugin interface that allows additional functionality to be added to the program by implementing a dynamically loadable library file. @@ -12,18 +12,30 @@ This interface allows programmers to develop additional functionality for VDR co separate from the core VDR source, without the need of patching the original VDR code (and all the problems of correlating various patches). <p> -This document describes the "outside" interface of the plugin system. -It handles everything necessary for a plugin to get hooked into the core +<!--X1.1.3--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +This document is divided into two parts, the first one describing the +<a href="#Part I - The Outside Interface"><i>outside</i> interface</a> +of the plugin system, and the second one describing the +<a href="#Part II - The Inside Interface"><i>inside</i> interface</a>. +The <i>outside</i> interface handles everything necessary for a plugin to get hooked into the core VDR program and present itself to the user. +The <i>inside</i> interface provides the plugin code access to VDR's internal data +structures and allows it to hook itself into specific areas to perform special actions. +<!--X1.1.3--></td></tr></table> <p> -<!--X1.1.1--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> +<!--X1.1.1--><table width=100%><tr><td bgcolor=lime> </td><td width=100%> Important modifications introduced in version 1.1.1 are marked like this. <!--X1.1.1--></td></tr></table> -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> Important modifications introduced in version 1.1.2 are marked like this. <!--X1.1.2--></td></tr></table> +<!--X1.1.3--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +Important modifications introduced in version 1.1.3 are marked like this. +<!--X1.1.3--></td></tr></table> <!--<p>TODO: Link to the document about VDR base classes to use when implementing actual functionality (yet to be written).--> +<a name="Part I - The Outside Interface"><hr><center><h1>Part I - The Outside Interface</h1></center> + <hr><h2>Quick start</h2> <center><i><b>Can't wait, can't wait!</b></i></center><p> @@ -117,7 +129,7 @@ from the web, it will typically have a name like <p> and will unpack into a directory named <p> -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> <tt>hello-0.0.1</tt> <!--X1.1.2--></td></tr></table> <p> @@ -125,7 +137,7 @@ To use the <tt>plugins</tt> and <tt>plugins-clean</tt> targets from the VDR <tt> you need to unpack such an archive into the <tt>VDR/PLUGINS/SRC</tt> directory and create a symbolic link with the basic plugin name, as in -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> <p><table><tr><td bgcolor=#F0F0F0><pre><br> ln -s hello-0.0.1 hello </pre></td></tr></table><p> @@ -191,7 +203,7 @@ its memory. You don't need to worry about the details behind all this. If your plugin requires additional source files, simply add them to your plugin's source directory and adjust the <tt>Makefile</tt> accordingly. <p> -<!--X1.1.1--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> +<!--X1.1.1--><table width=100%><tr><td bgcolor=lime> </td><td width=100%> Header files usually contain preprocessor statements that prevent the same file (or rather its contents, to be precise) from being included more than once, like @@ -410,7 +422,7 @@ If a plugin implements a function that runs in the background (presumably in a thread of its own), or wants to make use of <a href="#Internationalization">internationalization</a>, it needs to implement the function -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> <p><table><tr><td bgcolor=#F0F0F0><pre><br> virtual bool Start(void); </pre></td></tr></table><p> @@ -422,7 +434,7 @@ its task. This may, for instance, be a thread that collects data from the DVB stream, which is later presented to the user via a function that is available from the main menu. <p> -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> A return value of <i>false</i> indicates that something has gone wrong and the plugin will not be able to perform its task. In that case, the plugin should write a proper error message to the log file. The first plugin that returns @@ -486,7 +498,7 @@ interaction is possible. If a specific action takes longer than a few seconds, the plugin should launch a separate thread to do this. </b> -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> <hr><h2>Housekeeping</h2> <center><i><b>Chores, chores...</b></i></center><p> @@ -533,7 +545,7 @@ previously stored in the global setup data (see below). It shall return <i>true</i> if the parameter was parsed correctly, <i>false</i> in case of an error. If <i>false</i> is returned, an error message will be written to the log file (and program execution will continue). -<!--X1.1.1--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> +<!--X1.1.1--><table width=100%><tr><td bgcolor=lime> </td><td width=100%> A possible implementation of <tt>SetupParse()</tt> could look like this: <p><table><tr><td bgcolor=#F0F0F0><pre><br> @@ -588,7 +600,7 @@ needs setup parameters that are not directly user adjustable. It can use <tt>SetupStore()</tt> and <tt>SetupParse()</tt> without presenting these parameters to the user. -<!--X1.1.1--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> +<!--X1.1.1--><table width=100%><tr><td bgcolor=lime> </td><td width=100%> <a name="The Setup menu"><hr><h2>The Setup menu</h2> <center><i><b>Have it your way!</b></i></center><p> @@ -648,7 +660,7 @@ your setup parameters and use that one to copy all parameters with one single st (like VDR does with its cSetup class). <!--X1.1.1--></td></tr></table> -<!--X1.1.2--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<!--X1.1.2--><table width=100%><tr><td bgcolor=cyan> </td><td width=100%> <hr><h2>Configuration files</h2> <center><i><b>I want my own stuff!</b></i></center><p> @@ -815,16 +827,18 @@ and display their help and/or version information in addition to its own output. If you want to make your plugin available to other VDR users, you'll need to make a package that can be easily distributed. +<!--X1.1.3--><table width=100%><tr><td bgcolor=red> </td><td width=100%> The <tt>Makefile</tt> that has been created by the call to <a href="#Initializing a new plugin directory"><tt>newplugin</tt></a> -provides the target <tt>package</tt>, which does this for you. +provides the target <tt>dist</tt>, which does this for you. <p> -Simply change into your source directory and execute <tt>make package</tt>: +Simply change into your source directory and execute <tt>make dist</tt>: <p><table><tr><td bgcolor=#F0F0F0><pre><br> cd VDR/PLUGINS/SRC/hello -make package +make dist </pre></td></tr></table><p> +<!--X1.1.3--></td></tr></table> After this you should find a file named like @@ -835,5 +849,82 @@ vdr-hello-0.0.1.tgz in your source directory, where <tt>hello</tt> will be replaced with your actual plugin's name, and <tt>0.0.1</tt> will be your plugin's current version number. +<!--X1.1.3--><table width=100%><tr><td bgcolor=red> </td><td width=100%> +<a name="Part II - The Inside Interface"><hr><center><h1>Part II - The Inside Interface</h1></center> + +<hr><h2>Status monitor</h2> + +<center><i><b>A piece of the action</b></i></center><p> + +If a plugin wants to get informed on various events in VDR, it can derive a class from +<tt>cStatus</tt>, as in + +<p><table><tr><td bgcolor=#F0F0F0><pre><br> +#include <vdr/status.h> + +class cMyStatusMonitor : public cStatus { +protected: + virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber); + }; + +void cMyStatusMonitor::ChannelSwitch(const cDevice *Device, int ChannelNumber) +{ + if (ChannelNumber) + dsyslog("channel switched to %d on DVB %d", ChannelNumber, Device->CardIndex()); + else + dsyslog("about to switch channel on DVB %d", Device->CardIndex()); +} +</pre></td></tr></table><p> + +An object of this class will be informed whenever the channel is switched on one of +the DVB devices. It could be used in a plugin like this: + +<p><table><tr><td bgcolor=#F0F0F0><pre><br> +#include <vdr/plugin.h> + +class cPluginStatus : public cPlugin { +private: + cMyStatusMonitor *statusMonitor; +public: + cPluginStatus(void); + virtual ~cPluginStatus(); + ... + virtual bool Start(void); + ... + }; + +cPluginStatus::cPluginStatus(void) +{ + statusMonitor = NULL; +} + +cPluginStatus::~cPluginStatus() +{ + delete statusMonitor; +} + +bool cPluginStatus::Start(void) +{ + statusMonitor = new cMyStatusMonitor; + return true; +} +</pre></td></tr></table><p> + +Note that the actual object is created in the <tt>Start()</tt> function, not in the +constructor! It is also important to delete the object in the destructor, in order to +avoid memory leaks. +<p> +A Plugin can implement any number of <tt>cStatus</tt> derived objects, and once +the plugin has been started it may create and delete them as necessary. +No further action apart from creating an object derived from <tt>cStatus</tt> +is necessary. VDR will automatically hook it into a list of status monitors, with +their individual virtual member functions being called in the same sequence as the +objects were created. +<p> +See the file <tt>status.h</tt> for detailed information on which status monitor +member functions are available in <tt>cStatus</tt>. You only need to implement +the functions you actually want to use. +<!--X1.1.3--></td></tr></table> + </body> </html> |