From 771f0150b4de3209d9b1b788f15c8906333884fa Mon Sep 17 00:00:00 2001 From: Klaus Schmidinger Date: Sun, 21 Jul 2002 15:18:48 +0200 Subject: Added description of raw OSD access for plugins --- PLUGINS.html | 70 +++++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 22 deletions(-) (limited to 'PLUGINS.html') diff --git a/PLUGINS.html b/PLUGINS.html index 1781fcc6..3d450c25 100644 --- a/PLUGINS.html +++ b/PLUGINS.html @@ -12,7 +12,7 @@ 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).

-
  +
  This document is divided into two parts, the first one describing the outside interface of the plugin system, and the second one describing the @@ -23,18 +23,18 @@ The inside interface provides the plugin code access to VDR's internal da structures and allows it to hook itself into specific areas to perform special actions.

-
  -Important modifications introduced in version 1.1.1 are marked like this. -
-
  +
  Important modifications introduced in version 1.1.2 are marked like this.
-
  +
  Important modifications introduced in version 1.1.3 are marked like this.
-
  +
  Important modifications introduced in version 1.1.4 are marked like this.
+
  +Important modifications introduced in version 1.1.5 are marked like this. +

Part I - The Outside Interface

@@ -131,7 +131,7 @@ from the web, it will typically have a name like

and will unpack into a directory named

-
  +
  hello-0.0.1

@@ -139,7 +139,7 @@ To use the plugins and plugins-clean targets from the VDR you need to unpack such an archive into the VDR/PLUGINS/src directory and create a symbolic link with the basic plugin name, as in -
  +
  



 ln -s hello-0.0.1 hello

@@ -205,7 +205,6 @@ 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 Makefile accordingly.

-
  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 @@ -237,7 +236,6 @@ The 'hello' example that comes with VDR makes use of internationalization, it needs to implement the function -
  +
  



 virtual bool Start(void);

@@ -436,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.

-
  +
  A return value of false 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 @@ -500,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. -
  +
 

Housekeeping

Chores, chores...

@@ -547,7 +545,6 @@ previously stored in the global setup data (see below). It shall return true if the parameter was parsed correctly, false in case of an error. If false is returned, an error message will be written to the log file (and program execution will continue). -
  A possible implementation of SetupParse() could look like this: 



@@ -563,7 +560,6 @@ bool cPluginHello::SetupParse(const char *Name, const char *Value)
 
 It is important to make sure that the parameter names are exactly the same as
 used in the Setup menu's Store() function.
-

The plugin's setup parameters are stored in the same file as VDR's parameters. In order to allow each plugin (and VDR itself) to have its own set of parameters, @@ -602,7 +598,6 @@ needs setup parameters that are not directly user adjustable. It can use SetupStore() and SetupParse() without presenting these parameters to the user. -
 

The Setup menu

Have it your way!

@@ -660,9 +655,8 @@ You can first assign the temporary values to the global variables and then do th SetupStore() calls, or you can define a class or struct that contains all your setup parameters and use that one to copy all parameters with one single statement (like VDR does with its cSetup class). -

-
  +
 

Configuration files

I want my own stuff!

@@ -832,7 +826,7 @@ 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. -
  +
  The Makefile that has been created by the call to newplugin provides the target dist, which does this for you. @@ -854,7 +848,7 @@ vdr-hello-0.0.1.tgz in your source directory, where hello will be replaced with your actual plugin's name, and 0.0.1 will be your plugin's current version number. -
  +
 

Part II - The Inside Interface

Status monitor

@@ -931,7 +925,7 @@ member functions are available in cStatus. You only need to implement the functions you actually want to use.
-
  +
 

Players

Play it again, Sam!

@@ -1082,5 +1076,37 @@ that they already know. If you absolutely want to do things differently, just go ahead - it's your show...

+
  +

The On Screen Display

+ +
Express yourself

+ +Most of the time a plugin should be able to access the OSD through the +standard mechanisms also used by VDR itself. However, these set up the OSD in +a manner of textual rows and columns, and automatically set the various +windows and color depths. +

+If a plugin needs to have total control over the OSD, it can call the +static function + +



+#include <vdr/osd.h>
+
+cOsdBase *MyOsd = cOsd::OpenRaw(x, y);
+

+ +where x and y are the coordinates of the upper left corner +of the OSD area on the screen. Such a "raw" OSD doesn't display anything +yet, so you need to at least call the function + +



+MyOsd->Create(...);
+

+ +to define an actual OSD drawing area (see VDR/osdbase.h for the declarations +of these functions, and VDR/osd.c to see how VDR opens the OSD and sets up +its windows and color depths). +

+ -- cgit v1.2.3