Dbox2:Plugins:Tutorial (veraltet)
Diese Kategorie bzw. dieser Artikel basiert auf auf dem alten Buildsystem "Oldmake", welches ab Januar 2009 durch das jetzt im CVS-Head befindliche "Newmake" abgelöst wurde. Es ist relativ sicher, dass viele Funktionen nicht mehr aktiv unterstützt werden oder nicht mehr funktionieren. Es besteht aber die Möglichkeit "Oldmake" weiterhin zu warten. Der letzte funktionsfähige Stand wurde im CVS mit dem Tag
last_oldmake_head
markiert und ein entsprechender Branch
oldmake
angelegt, so dass das Verfahren, wenn auch eingeschränkt, weiter verwendet werden kann. Von den meissten aktiven Entwicklern wird dieser Branch jedoch nicht mehr weiter gepflegt, so dass es am Nutzer selbst liegt, notwendige Änderungen im Entwicklerforum mitzuteilen oder sofern die Möglichkeit besteht, selbst entsprechende Änderungen ins CVS zu schreiben.
Inhaltsverzeichnis
Allgemeines
Es gibt viele Leute, die eigene Ideen für Verbesserungen der Dbox2-Software haben.
Im Forum heißt es da oft: Ist doch OpenSource, mach es halt selber.
Doch das ist gar nicht so einfach, denn nicht jeder ist ein Programmierer und kann die bestehenden Quelltexte lesen wie andere ein Buch. Dazu kommt noch, dass man eine Menge anderer Dinge tun muss, bevor man endlich damit beginnen kann seine neue Idee zu verwirklichen.
Man muss erst einmal eine Programmier-Umgebung (CDK) aufbauen, die ausführbare Dateien für die DBox2 erstellen kann. Das funktioniert am besten unter Linux.
Hat man diese Einstiegshürde erst einmal gemeistert, dann steht man gleich vor dem nächsten Problem: Wo anfangen?
Meiner Meinung nach können die meisten Ideen durch ein Plugin realisiert werden.
Und genau darum soll es auch in diesem Tutorial gehen. Wie erstelle ich ein eigenes Plugin und binde dieses in das CDK und später in die DBox2 ein.
Plugin-Grundgerüst
Um ein eigenes Plugin zu erstellen braucht man zunächst einmal die eigentlichen Quelltexte des Plugins.
Im einfachsten Fall sind dies eine .c und eine .h Datei, in unserem Tutorial werden dies testplugin.c und testplugin.h sein.
Außerdem müssen wir dem Programm, das das Plugin aufrufen soll (Neutrino oder Enigma) mitteilen, welche Eigenschaften unser neues Plugin hat, bzw. welche Ressourcen es benötigt.
Dies wird mit einer Plugin-Konfigurationsdatei (testplugin.cfg) erreicht, deren Inhalt folgendermaßen aussieht
type=2
name=Testplugin
desc=Test zur Pluginerstellung
needfb=0
needlcd=0
needrc=0
needoffsets=0
Eine Erklärung, was die einzelnen Parameter der .cfg-Datei bedeuten, findet man hier.
Hello World
Nun zum eigentlichen Programm. Da es mir hauptsächlich darum geht zu zeigen, wie man ein eigenes Plugin in das CDK einbindet, hier das einfachste aller Beispiele:
testplugin.h
#include "stdio.h"
#include "plugin.h"
testplugin.c
#include "testplugin.h"
void plugin_exec(PluginParam *par)
{
printf("Hallo Welt\n");
return;
}
Das ist zugegebenermaßen kein Plugin mit einer supertollen Funktion, aber es reicht um alles weitere testen zu können. Startet man dieses Plugin, so wird der Text "Hallo Welt" auf der Konsole ausgegeben, nicht mehr, aber auch nicht weniger.
Einbindung des neuen Plugins ins CDK
Um das neue Plugin-Verzeichnis und die neuen Quelltext-Dateien ins CDK einzubinden, muss als erstes im Plugin-Verzeichnis die Datei Makefile.am erstellt werden.
Hier einmal die Makefile.am unseres Test-Plugins als Beispiel:
AM_CPPFLAGS = \
@FREETYPE_CFLAGS@ \
-I$(top_srcdir)/include
noinst_LTLIBRARIES = testplugin.la
testplugin_la_SOURCES = testplugin.c
if BOXTYPE_DREAMBOX
testplugin_la_CFLAGS = -DOLDFT
endif
testplugin_la_LIBADD = \
@FREETYPE_LIBS@
testplugin_la_LDFLAGS = -rpath $(PLUGINDIR) -module -avoid-version
install-exec-local:
install -d $(DESTDIR)$(PLUGINDIR)
install -d $(DESTDIR)$(CONFIGDIR)
install -d $(DESTDIR)$(CONFIGDIR)/testplugin
$(LIBTOOL) --mode=install install testplugin.la $(DESTDIR)$(PLUGINDIR)
install -m 0644 $(srcdir)/testplugin.cfg $(DESTDIR)$(PLUGINDIR)
Dann muss man nur noch im Verzeichnis
~/yadi/tuxbox-cvs/apps/tuxbox/plugins
die beiden Dateien configure.ac und Makefile.am editieren.
In der Datei configure.ac werden ab Zeile 32 die Makefiles der einzelnen Plugins aufgelistet. Hier muss man das neue Plugin ergänzen.
AC_OUTPUT([
Makefile
include/Makefile
fx2/Makefile
fx2/lemm/Makefile
fx2/master/Makefile
.
.
.
enigma/ngrabstop/Makefile
enigma/dslconnect/Makefile
enigma/dsldisconnect/Makefile
testplugin/Makefile
tuxbox-plugins.pc
])
Als letzten Schritt zur Einbindung des neuen Plugins muss noch die Makefile.am im Plugins-Verzeichnis ergänzt werden.
AUTOMAKE_OPTIONS = gnu
if BOXTYPE_DREAMBOX
SUBDIRS = \
include tuxmail tuxtxt tuxcom fx2 enigma testplugin
else
SUBDIRS = \
include tuxmail tuxtxt tuxcom fx2 vncviewer enigma testplugin
endif
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = \
tuxbox-plugins.pc
Das war's auch schon. Durch einen Aufruf des Compilers (siehe nächster Abschnitt) werden nun die restlichen benötigten Dateien automatisch erzeugt.
Kompilieren des Plugins
Hat man bisher alles korrekt ausgeführt, dann kommt jetzt der einfache Teil 
Man wechselt auf der Kommandozeile ins CDK-Verzeichnis
cd ~/yadi/tuxbox-cvs/cdk
Dort führt man die folgenden 2 Befehle aus
rm .deps/plugins
make plugins
Beim ersten Aufruf dieser Zeilen werden die benötigten Make-Dateien vom System erstellt und anschließend ausgeführt.
Bei weiteren Aufrufen werden die Plugins, bei denen etwas im Quelltext geändert wurde, neu kompiliert.
Nur ein einzelnes Plugin neu zu kompilieren ist mir mit meinem momentanen Wissensstand noch nicht gelungen, was aber auf keinen Fall heißt, dass es nicht möglich ist.
Wurde das Plugin fehlerfrei compiliert, dann befinden sich anschließend 3 neue Dateien im Verzeichnis
~/yadi/dbox/cdkroot/lib/tuxbox/plugins
In unserem Beispiel sind die folgenden Dateien dort neu:
~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.so
Dies ist das eigentliche Binary, die Plugin-Datei.
~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.cfg
Dies ist die von uns erstellte Konfigurationsdatei, in der das Hauptprogramm vor dem Ausführen des Plugins nachsieht, welche Ressourcen unser Plugin benötigt.
~/yadi/dbox/cdkroot/lib/tuxbox/plugins/testplugin.la
Wofür diese Datei genau ist, weiß ich auch nicht genau, vielleicht kann das mal ein schlauerer Mensch ergänzen
Testen des Plugins
Um das Plugin auf der DBox2 zu testen, gibt es mehrere Möglichkeiten.
1. Man kopiert diese 3 Dateien per FTP auf die DBox2 ins Verzeichnis
/lib/tuxbox/plugins/
Dabei ist zu beachten, dass die .so Datei ausführbar sein muss. Dies kann man entweder mit seinem FTP-Programm erledigen, oder aber per telnet auf der DBox2:
cd /lib/tuxbox/plugins/
chmod +x testplugin.so
2. Man richtet einen NFS-Server auf seiner Entwicklungsmaschine ein und mountet das Pluginsverzeichnis direkt auf die DBox2
Wie man den NFS-Server einrichtet, hängt von der Entwicklungsmaschine ab, deshalb überspringe ich das einfach ;O)
Das Mounten auf der DBox2 erledigt man dann mit folgendem Befehl:
mount -t nfs <server-ip>:/<verzeichnis> /mnt/plugins -o ro,soft,nolock,udp,rsize=32768,wsize=32768
Bei meinem System sieht das dann so aus:
mount -t nfs 192.168.60.210:/home/chrrh/yadi/dbox/cdkroot/lib/tuxbox/plugins /mnt/plugins -o ro,soft,nolock,udp,rsize=32768,wsize=32768
Ist Punkt 1 oder Punkt 2 erledigt, kann man im z.B. bei Neutrino im Menü [d-box]->Service->Plugins neu laden die Plugins neu einlesen. Jetzt sollte in der Plugin-Liste das neue Plugin auftauchen und ganz normal über die Fernbedienung gestartet werden können.
Ich wünsche viel Spaß mit dem neuen Plugin und vor allem viel Erfolg beim Entwickeln eigener Plugins.
Grundlagen - Installation - Debug-Mode - Hardware - CDK/Development
LCars - Neutrino - Enigma - Plugins - Spiele - Software - Tools - Howto - FAQ - Images
Hauptseite - News - Alle Artikel - Bewertungen - Gewünschte Seiten - Index - Neue Artikel - Impressum - Team
Hilfeportal - Seite bearbeiten - Bilder - Links - Tabellen - Textgestaltung
