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 direkt. Allerdings ermöglicht die Nutzung der Web-API, die GUI und diverse interne Funktionen zu steuern und auch zum Teil auch Rückmeldungen auswerten zu können.

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)

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.

Lua:Neutrino-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 dazu unter Lua-Neutrino-API

Speicherort und Berechtigungen

Je nach Build Konfiguration sind die Plugins entsprechend abgelegt.

In aktuellen Tuxbox-Images sind die Plugins hier abgelegt:

/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

Zusätzlich werden Speicherorte auf möglichen Laufwerken zugeordnet, die vom Benutzer angegeben werden können.

g_settings.plugin_hdd_dir /media/sda1/plugins

Plugins, die in diesen Ordnern gefunden werden, erscheinen auch in den Neutrino-Menüs. Scripte und Programme müssen ausführbar sein.

Plugin-Beschreibungen

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 Plugins, die bisher noch nicht den Weg ins GIT gefunden haben, sind im Umlauf, aber auch verschiedene gepatchte Varianten von Originalplugins, wie dies beispielsweise öfter bei Shellexec-Plugins der Fall ist, sieht man recht oft. Diese dienen oft dazu, nicht die Funktionen des Plugins im eigentlichen Sinne zu nutzen, sondern es werden damit diverse Tools, also für die Geräte kompilierte Programme oder auch Skripte ausgeführt, die dann die gewünschten Aufgaben übernehmen.

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.