Plugins

Plugins sind Erweiterungen, die nicht zwingend notwendig für den eigentlichen Betrieb des Systems sind. Über Plugins können weitere nützliche Funktionen zu den GUIs hinzugefügt werden. Bei den meisten Images sind bereits einige Plugins enthalten.

Plugins entwickeln

Eigenständige Tools und Scripte

Viele Plugins sind eigentlich eigenständige Programme oder Skripte, die selbständig arbeiten und unabhängig von der GUI programmiert wurden. Die Einbindung in die GUI erfolgt lediglich in der Regel über deren Konfigurationsdateien. Dabei werden diese Plugins von Neutrino je nach Konfiguration in das jeweilige Menü mit einer bestimmten Anzeige- und Integrationsoption geladen und angezeigt.

Ein Nachteil eigenständiger Plugins ist es, dass man nicht direkt auf vorhandene interne Ressourcen der GUI zurückgreifen kann und quasi alles was so ein Plugin bzw. Programm benötigt gewissermaßen eigenständig programmiert werden muss. Möglichkeiten, um zum Beispiel direkt auf grafische Darstellungsroutinen der GUI wie NeutrinoHD/MP zugreifen zu können, gibt es damit also nicht. Allerdings ermöglicht die Nutzung der Web-API, die GUI und diverse interne Funktionen zu steuern, mit der zum Teil auch Rückmeldungen ausgewertet werden können.

Möchte man die Ressourcen der GUI nutzen, bietet die Lua-API einen gewissen Umfang an Möglichkeiten. Diese wird je nach Bedarf auch weiterhin erweitert, sodass interne Funktionen mehr und mehr genutzt werden können. Dies hat allerdings zur Folge, dass man auf Kompatibilität achten muss.

Kleiner historischer Aspekt: Anfangs gab es auch die Möglichkeit diese Plugins ähnlich wie Libraries einzubinden (siehe#Shared Library), was aber inzwischen nicht mehr bzw. nur in älteren Versionen möglich war.

• Tutorial (obsolete)

Es gibt inzwischen viele verschiedene Plugins für die unterschiedlichsten Verwendungszwecke. Darunter sind einige, die standardmäßig im GIT liegen, von denen die meisten auch in diversen Images eingebaut sind. Auch einige portierte Spiele, die früher auf der DBox2 zu finden waren, gehören dazu. Auch verschiedene 3rdParty oder Community Plugins, die bisher noch nicht den Weg ins GIT gefunden haben, sind im Umlauf, aber auch verschiedene gepatchte Varianten von Originalplugins.

Lua-API

Lua-API bietet die Möglichkeit, bei NeutrinoHD/MP den Zugriff auf GUI-Resourcen über eine Lua-Schnittstelle zu ermöglichen.

Beispiele und die Dokumentation: Lua-Neutrino-API

Speicherort und Berechtigungen

Je nach Build Konfiguration sind die Plugins entsprechend abgelegt.

Scripte und Programme müssen ausführbar sein.

In aktuellen Tuxbox-Images sind die Plugins hier abgelegt: Plugins, die in diesen Ordnern gefunden werden, erscheinen auch in den Neutrino-Menüs.

/usr/share/tuxbox/neutrino/plugins

Dies wird über die Neutrino Build-Optionen mitgegeben.

--with-plugindir=/usr/share/tuxbox/neutrino/plugins
--with-plugindir_var=/etc/neutrino/plugins
--with-luaplugindir=/usr/share/tuxbox/neutrino/plugins
--with-gamesdir=/etc/neutrino/plugins

Sofern vorhanden, sind die mit /var versehenen Pfade dem Benutzer vorbehalten und im Image standardmäßig nicht bestückt.

Zusätzlich werden Speicherorte für möglichen Laufwerke zugeordnet, die vom über Neutrino-Einstellungen angepasst werden können.

g_settings.plugin_hdd_dir /media/sda1/plugins

Konfiguration

Zu jedem Plugin, egal ob Tool, Script, oder Lua-Script gehört auch eine namensgleiche *.cfg Datei, welche die Konfiguration eines Plugins enthält. Darin werden die benötigten Schlüssel mit Optionswerte bzw. Config-Optionen hinterlegt. Darin werden Anzeige-Optionen, Beschreibungen, Plugin-Typ und Integration festgelegt. Wichtig ist, dass diese Dateien den gleichen Namen wie das Plugin selbst haben und die Endung .cfg besitzt. Das Plugin selbst hat die Endung .sh, .so, .lua oder falls es ein Programm ist nur den Eigennamen.

Config-Optionen

• type=
• name=
• desc=
• index=
• key=
• hide=
• shellwindow=
• integration=
• hinticon=

Veraltet, wird nicht mehr verwendet:

• needfb
• needrc
• needlcd
• needvtxtpid
• needoffsets
• picon

Typen

• type=0 deaktiviert
• type=1 Spiele
• type=2 Werkzeug (in der Regel unter Features bzw. blaue Taste zu erreichen)
• type=3 Script (unter Scripte und teilweise über blaue Taste zu finden)
• type=4 LUA-Plugin

Name

• name=<plugin>

Name des Plugins. Dieser wird entprechend in den Menüs angezeigt.

Beschreibung

• desc=<Standardbeschreibung des Plugins>

Dieser Text wird in der Hinweisbox des Menüs angezeigt, wenn dieses Menü angewählt ist. Zusätzlich ist eine Lokalisierung möglich.

• desc=<Standardbeschreibung des Plugins>
• desc.deutsch=<Beschreibung des Plugins in deutsch>
• desc.english=<Description of plugin in english>

Index

• index=<n>

Damit wird Anordnung innerhalb der Reihenfolge der Menüeinträge der anzuzeigenden Plugins bestimmt. Je kleiner der Index "n" ist, umso näher befindet sich das Plugin in der Menüliste. Wird kein Index angegeben, wird nur nach Name sortiert, der in der .cfg-Datei vergeben ist. Außerdem werden die Plugins aus dem Benutzerordner zuerst angezeigt, dann die Übrigen.

Integration

• integration=0 undefiniert(Anzeige über blaue Taste)
• integration=1 reserviert, keine Funktion
• integration=2 Hauptmenü > Multimedia
• integration=3 Hauptmenü > Einstellungen
• integration=4 Hauptmenü > Service
• integration=5 Hauptmenü > Informationen
• integration=6 Hauptmenü > Service > Software-Aktualisierung

• gültige Optionswerte im Neutrino Quellcode: https://github.com/tuxbox-neutrino/gui-neutrino/blob/master/src/plugin.h#L16

Alle Plugin-Typen, also Scripts, ausführbare Programme oder Lua-Skripte können in ein vom Kontext her passendes Neutrino-Menü integriert werden. Hierfür muss nur der passende Wert in die zum Plugin gehörende *.cfg Datei eingetragen werden. Hier als Beispiel das Startup (Multiboot)-Plugin, welches im Menü Einstellungen verfügbar ist.

name=Multiboot
desc=Switch boot partition
desc.deutsch=Boot-Partition wechseln
type=4
integration=3

Begriffserklärung

Shared Library

Diese Möglichkeit gab es in den Anfängen des Tuxbox-Projekts, wird aber jetzt nicht mehr verwendet. Diese Ausführungen sind daher nur der Vollständigkeit hier angegeben. Shared Librarys sind Bibliotheken, die dynamisch je nach Gebrauch in den Arbeitsspeicher geladen werden. Sind diese Bibiotheken einmal im Speicher vorhanden, können Programme auf deren Funktionen etc. zugreifen. Gerade diese Methode hat Geschwindigkeitsvorteile gegenüber Static Libraries (Statischen Bibiotheken), weil dort die Bibiothek statisch in die Datei eingebunden wird. Shared Libraries benutzen PIC (Position Independend Code == Positionsunabhängiger Maschinencode). Dieser Code ist positionsunabhängig und ist an keine fixen Adressen gebunden.

Methodik

Wie funktioniert das denn nun? Das ist ganz einfach:

Programme, die zur Verwendung von Shared Libraries compiliert wurden, enthalten Dummycode (auch als stub code bezeichnet). Dieser Dummycode ist sozusagen ein Platzhalter, für die wirklichen Funktionen, etc. Wenn Sie das Programm nun starten, versucht der Lader (ein Teil des Betriebssystemes), diese Bibiotheken zu finden und zu laden. Wie oben schon erwähnt, schaut der Lader nach, ob diese Bibiothek schon mal geladen wurde, wenn ja, wird gelinkt, wenn nicht, wird diese geladen und gelinkt. Das Linken geschieht so: Die Bibliothek wird in den Adressspace (Adressraum) des Prozesses gemappt, und die Adressen zu dem Dummycode, werden auf die der Bibliotheken gewechselt.

Das dynamische Linken hat einige Vorteile:

• Statisch gelinkte Programme, benutzen nur den Code der während des Erstellens bzw. Compilierens fest "eingebaut" wurde. Wenn nun Änderungen an den Libraries vorgenommen wurden, müssen diese Programme neu compiliert werden.

Beispiel:

Einige Programme (von unterschiedlichen Herstellern) sind von einer Bibliothek abhängig, die wichtige I/O-Operationen durchführt. Es werden nun Fehler bekannt, und die Library wurde überarbeitet. Das Blöde ist nun, dass alle Programme neu kompiliert werden müssen, damit diese die Änderung mitbenutzen. Das wäre Kosten- und Zeitaufwendig (Updates etc.). Würde aber nun nur die Bibiothek ausgetauscht werden, müssten die Programme (Voraussetzung: Benutzung von Shared Libraries) nicht geändert werden, und es würden keine Kosten für die Hersteller aufkommen, da diese Programme, die Änderung beim Aufruf übernehmen.

• Statisch gelinkte Programme nehmen mehr Speicherplatz weg. Aufgrund der Tatsache, dass Programme die statisch gelinkt wurden, den Code der Bibliotheken jedesmal in den Arbeitsspeicher kopieren, nimmt der freie Platz immer mehr ab.
• Leichtere Programmpflege: Es muss nur die Library ausgetaucht werden und nicht das komplette Programm.