Skindesigner 0.0.4: Plugin Interface

  • Moin,


    im Git ist nun die Version 0.0.4 vom Skindesigner. Alle Änderungen seit der Version 0.0.3 finden sich in der History.


    Neben vielen Fixes ist die wichtige Neuerung das Plugin Interface. Es ermöglicht anderen Plugins, die Template Engine vom Skindesigner mit zu benutzen. Plugins können somit eigene Menülisten (wie bei Schedules, Channels, Timers, Recordings) und eigene Detailansichten darstellen, die auf Skindesigner Templates basieren. Dabei können natürlich alle Features vom Skindesigner benutzt werden. Das Plugin funktioniert natürlich auch mit Nicht-Skindesigner-Skins und mit Skindesigner Skins, die keine dedizierten Templates für das Plugin zur verfügung stellen. In diesen Fällen werden die Standardansichten vom VDR benutzt.


    Ich habe in den Skindesigner Sourcen ein Beispiel Plugin skindesclient-0.0.1 hinterlegt, das die Funktionsweise demonstriert. Ein Plugin, dass das Skindesigner Interface benutzen will, muss das libskindesigner Verzeichnis beinhalten und im Makefile libskindesigner/skindesignerosdbase.o als Objekt inkludieren. Dadurch werden die Klassen cSkindesignerOsdMenu und cSkindesignerOsdItem zur Verfügung gestellt, von denen nun die entsprechenden Objekte im Plugin anstelle von cOsdMenu bzw. cOsdItem erben müssen. Im Beispielplugin ist eigentlich alles notwendige demonstriert...über das Interface müssen dann einfach nur zusätzlich Tokens an den Skindesigner übergeben werden, die dann in den Templates zur verfügung stehen und benutzt werden können.


    Beim Start des Plugins müssen Skindesigner per Servicecall die zu benutztenden Templates bekannt gemacht werden. Die Templates müssen im "xmlfiles" Verzeichnis des jeweiligen Skins vorhanden sein. Als Namenskonvention wird "plug-<pluginname>-<templatename>.xml" benutzt.


    Ich denke, das neue Plex Plugin möchte das gerne nutzen :D Es spricht aber auch nichts dagegen, bestehende Plugins dahingehend zu erweitern, dass optional Templates benutzt werden. Das Mail Plugin böte sich z.B. an, da könnte man dann eine Vorschauansicht für die Mails in der Liste der Mails (wie in Outlook) basteln. Ich habe da mal kurz reingesehen, das war mir aber ehrlich gesagt zu "komisch" implementiert, als dass ich das auf die schnelle hätte umstellen können ;) Vielleicht mag sich das ja mal jemand anschauen, der Lust darauf und Bedarf daran hat.



    Ciao Louis

  • Upps, sollte ausgerechnet der VDR auf seinen Alten Tagen noch zur Konkurrenz von Plex Home Theater, XBMC/PLEXBMC erwachsen?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Upps, sollte ausgerechnet der VDR auf seinen Alten Tagen noch zur Konkurrenz von Plex Home Theater, XBMC/PLEXBMC erwachsen?


    Schaumer mal ;) Ist zwar erst mal ein recht "primitives" Interface und nur für Plugins geeignet, die sich der VDR Menüs bedienen und nicht alles selber zeichnen...aber man muss ja erst mal auch noch ein bisschen Luft nach oben lassen, was nicht ist kann ja noch werden :D


    Ciao Louis

  • Zitat von »gda«



    Upps, sollte ausgerechnet der VDR auf seinen Alten Tagen noch zur Konkurrenz von Plex Home Theater, XBMC/PLEXBMC erwachsen?


    Schaumer mal ;) Ist zwar erst mal ein recht "primitives" Interface und nur für Plugins geeignet, die sich der VDR Menüs bedienen und nicht alles selber zeichnen...aber man muss ja erst mal auch noch ein bisschen Luft nach oben lassen, was nicht ist kann ja noch werden :D


    Na ja, ich denke zumindest schon mal nach über einen OpenELEC-Fork mit VDR statt XBMC als Hauptanwendung nach.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Geilomat :)
    Wie auf Bestellung :)


    Na dann hau mal rein ;)


    Eigentlich sollte die Verwendung durch das skindesclient Plugin mehr oder weniger selbsterklärend sein. Wenn es aber Fragen gibt oder irgendwas aus deiner Sicht noch nicht passen sollte, als her damit ;)


    Ciao Louis

  • Das Einbinden von Objektdateien aus anderen Plugins ist eine blöde Krücke, die für Paketbauer unmöglich einzuhalten ist.
    Was auch immer da von anderen Plugins gebraucht wird, muss in eine eigenständige lib inkl. Header (die natürlich gerne vom vdr abhängig sein darf wegen der vdr-Header) und dann kann es von skindesigner und anderen Plugins benutzt werden. Sonst taugt das nichts.


    Nicht falsch verstehen, ich möchte nur konstruktive Kritik üben. :)


    Lars

  • Es wird nichts "aus anderen Plugins" eingebunden. Zumindest wenn ich das richtig verstanden habe. Die Idee ist es, dass Plugins, die das nutzen wollen, die entsprechenden Source-Dateien in ihren eigenen Source kopieren sollen. Wenn Louis daran gedacht hat in seinem Service-Interface eine Versionsnummer zu hinterlegen sollte es damit keine Probleme geben und die Distributoren müssen sich um garnichts kümmern.

  • Das hat überhaupt nichts mit dem Service-Interface zu tun. Es sind zwei header und eine Source-Datei.
    Daraus könnte man so schön eine eigene lib erstellen, die dann von den Plugins, die es nutzen wollen, eingebunden werden könnte, damit eben nicht der Source in verschiedenen Plugins evtl. sogar in unterschiedlichen Versionen vorliegen muss/wird.


    Sie hat ja sogar schon einen Namen, es fehlt nur noch ein passendes Makefile. Ich schaue mal, ob ich da morgen mal was gebastelt bekomme. Dann sollte es seinen eigenen tarball kriegen und alles ist gut.


    Source kopieren... Lasst uns bitte nicht so anfangen. Bei einem struct für einen Servicecall hab ich es ja schon aufgegeben, aber hier ist es was anderes.


    Lars.

  • Ich habe mal alles was hier publiziert wurde für Yavdr in Pakete gebaut:


    vdr-plugin-skindesigner - skindesigner skin template for VDR
    vdr-plugin-skindesigner-dbg - skindesigner skin template for VDR - debugging symbols
    skindesigner-skin-elchi - skin elchi for skindesigner
    skindesigner-skin-nopacityfrodo - skin nopacityfrodo for skindesigner (Die Fonts vom Original von Louis waren mir zu groß)
    skindesigner-skin-holo - skin holo for skindesigner
    skindesigner-skin-3popacity - skin 3popacity for skindesigner


    Aber Achtung getestet habe ich es nur gegen meinen 2.1.6er VDR aus meinem testing-vdr-dev.


    Was noch fehlt ist ein Paket für die Logos, ich habe aber das Plugin gegen die Logos (vdr-channellogos) vom Gandalf Repository (ppa:gandalf-der-grosse/main) verlinkt.


    Für alle die das Holo Skin möchten wird zusätzlich mein Main Repository benötig da dort die Fonts liegen, allerdings werden hier auch ein paar Librarys aktualisiert, wer das nicht möchte sollte sich die Fonts lieber herunterladen und mit "dpkg -i" installieren

    Code
    add-apt-repository ppa:frodo-vdr/main


    Precise: https://launchpad.net/~frodo-v…untu1.3%7Eprecise_all.deb
    Trusty: https://launchpad.net/~frodo-v…buntu1.2%7Etrusty_all.deb


    Yavdr stable-vdr VDR 2.0 (precise):

    Code
    add-apt-repository ppa:frodo-vdr/stable-yavdr-plugins


    Yavdr testing-vdr VDR 2.0 (trusty/precise):

    Code
    add-apt-repository ppa:frodo-vdr/testing-yavdr-plugins


    Yavdr testing-vdr-dev VDR 2.1.6 (precise) :

    Code
    add-apt-repository ppa:frodo-vdr/testing-vdr-dev


    Nachtrag: Ich habe die Skin Pakete umbenannt, wer bereits die Pakete mit den alten Namen verwendet hat wird automatisch auf die neue Namensgebung umgestellt. Siehe auch Beitrag weiter unten von Copperhead.

    Gruß
    Frodo

    Einmal editiert, zuletzt von Frodo ()

  • Sei nicht so kleinlich :D


    Beim VDR heist der Ordner auch theme und nicht skin 8)

    Gruß
    Frodo

  • Das hat überhaupt nichts mit dem Service-Interface zu tun. Es sind zwei header und eine Source-Datei.


    Doch. Hat es. Schau mal genau in die Source-Dateien.


    Das einzige, das Louis meiner Ansicht nach vergessen hat ist die Versionsnummer am Aufruf der Service-Schnittstelle. Kann man in der Zukunft aber leicht nachrüsten. Dann ist der Aufruf ohne Version eben die "1.0".


    Versions-Nummer deshalb, weil die Source-Bestandteile eben nunmal in Plugin-Sourcen liegen. Sauber funktioniert das nur, wenn bei einer Änderung der Schnittstelle auch die alten noch funktionieren und das Service-Plugin anhand der Versions-Nummer ggf. eine alte Struktur nutzt.


    Das Problem wird aber auch mit "Ausgelagerten Sourcen" kaum besser. Zumal für eine ".so" wohl noch etwas mehr gemacht werden muss als einfach die drei Source-Dateien zu kompilieren. Bei ausgelagerten Sourcen müsste man sich heute schon auf eine stabile API einigen, die man auch in Zukunft nicht inkompatibel ändern sollte. Sonst müsste man nämlich ständig alle Plugins neu bauen, die das neue Feature vom Skindesigner nutzen wollen.


    Zitat


    Daraus könnte man so schön eine eigene lib erstellen, die dann von den Plugins, die es nutzen wollen, eingebunden werden könnte, damit eben nicht der Source in verschiedenen Plugins evtl. sogar in unterschiedlichen Versionen vorliegen muss/wird.


    Gibt es eigentlich einen Grund warum Debian-Entwickler ein "Ganzes" immer in viele kleine Teile zerstückeln wollen? ;)

  • Moin,


    so ganz sehe ich die Argumentation von Lars auch noch nicht ein...wenn ich es richtig verstehe, würde dann die Lib vom skindesigner aus gebaut und zur Verfügung gestellt werden? Das hätte den Nachteil, dass die Lib gar nicht da wäre, wenn der skindesigner nicht installiert ist.


    Nach "meiner" Methode kopiert das Plugin, das die Schnittstelle benutzen will, einfach das "libskindesigner" Verzeichnis in seine Sourcen und benutzt es...und es ist völlig egal, ob der Skindesigner installiert ist oder nicht.


    Vielleicht verstehe ich aber auch was falsch...aber ein bisschen mehr Argumentation wäre nicht schlecht, ich bin noch nicht überzeugt ;)


    Ciao Louis

  • ich bin kein entwickler, aber:


    Zitat

    das die Schnittstelle benutzen will, einfach das "libskindesigner" Verzeichnis in seine Sourcen und benutzt es...


    klingt katastrophal.
    sobald es ein update des "libskindesigner" gibt und der plugin autor reicht das nicht zügig nach kracht es an allen enden.
    und man weiss erstmal nicht woher das kommt.


    oder hab ich jetzt den sinn der libs falsch verstanden ? (als nichtentwickler)


    beim zerstückeln ist das ja genau der vorteil.
    man kann dem plugin paket (debian, ubuntu, gentoo bestimmt auch) sagen: hey dein plugin passt nicht zur neuen version der lib und läuft so nicht mehr.
    also laden wir das plugin nicht, bis es angepasst wurde bzw. gegen die "neue" lib gebaut wurde .... basta und gut.

  • sobald es ein update des "libskindesigner" gibt und der plugin autor reicht das nicht zügig nach kracht es an allen enden.
    und man weiss erstmal nicht woher das kommt.


    Wenn die Schnittstelle erweitert werden würde wäre das natürlich abwärtskompatibel, sodass es nicht krachen würde. Aber zugegeben, wenn ich eine Änderung machen müsste, die aus irgendwelchen Gründen die Abwärtskompatibilität nicht einhalten könnte, dann wäre das Scheisse :D Naja, schaumer mal, was Lars so konkret vorschlägt...ich bin ja lernwillig ;)


    Ciao Louis

  • Ja, weil da ja auch die Themes drinliegen.
    Skins kommen in den VDR als Plugin. In dem Fall SkinDesigner und dort heißt das Verzeichnis "skins"


    Ich werde die theme/skin Pakete umbenennen.


    skindesigner-theme-skinelchi = skindesigner-skin-elchi


    Da fällt mir gerade auf müsste den Dein skinelchi nicht besser nur "elchi" heißen? ?(
    Alle anderen Skins, haben kein skin in Ihren Namen und nur weil das skin als skinelchi sein Licht in der Welt erblickt hat muss man das ja auch nicht für immer beibehalten.


    Die Umstellung der Namen ist abgeschlossen, ich habe die Paketnamen der Skins nun alle auf skindesigner-skin-name umbenannt. Die alten Pakete werden bei einem "apt-get update && apt-get dist-upgrade" automatisch umgestellt.

    Gruß
    Frodo

    Einmal editiert, zuletzt von Frodo ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!