[ANNOUNCE] VDR developer version 1.7.37

Moin!

Zitat von Mreimer

Letzteres würde dann auch voraussetzen, dass man dann erst die "Service-Plugins" bauen muss und danach die abhängigen Plugins.

Man muss das Service-Plugin nicht bauen, wenn man nur einen Header braucht.
Das ist der Vorteil der -dev-Pakete und sorgt für eine Entkoppelung der Abhängigkeiten. Die -dev-Pakete sind die .h-Dateien eines Projekts. Und über den Sinn von .h-Dateien müssen wir sicherlich nicht streiten...

Zitat von Mreimer

Dev-Pakete gibt es bei Archlinux per Definition nicht.

Kein Problem. Dann würde ich wie oben schon mal beschrieben ein Paket "Service-Interface" und ein Paket "Service-Plugin" machen, das Plugin-Makefile (nicht *alle* Plugin-Makefiles, sondern nur die, die es anbieten möchten) erstellt beim "make dist" einfach zwei passende Tarballs und schon hat Arch wieder ein Paket pro Quelle. Dabei ist "Service-Plugin" eben abhängig von "Service-Interface".

Aber ich verstehe deinen Standpunkt. Ich möchte mich auch eher an die Plugin-Entwickler richten. Und wenn ich da ein paar finde, mit denen ich mich auf einen gewissen Standard einigen kann, dann reicht mir das.
Das Grundgerüst hätte ich gerne (wie oben schon erwähnt) als Dokumentation im newplugin-Script, aber ich kann auch ohne leben.
Ich werde mich mit meinen Patches dann einfach an die entsprechenden Plugin-Autoren wenden.
Mir war es in erster Linie wichtig, einen gemeinsamen Ort für die Header zu finden, und zumindest da scheint es ja keine Widersprüche zu geben: "$INCDIR/vdr/plugins/$PLUGIN/"
Meine Plugins (die, die es brauchen) werden da ihre Schnittstellen-Header installieren, fertig. Wenn jemand das nutzen möchte (oder es mir nachmachen möchte), würde ich mich freuen.
Oder spricht etwas dagegen, den öffentlichen Teil meiner Plugin-API (die ohne die Plugin-lib auskommt!) allgemein zur Verfügung zu stellen?

Lars.

Zitat von Keine_Ahnung

Wenn Versionsabhängig ist kann man im Plugin ne Abhängigkeit gegen eine bestimmte dev Version des Serverplugins festlegen. Das ist klarer als wenn eine falsche Kopie des Headerfiles (was nicht zum geänderten Serverplugin passt) beim Plugin liegt. Dann muss man nämlich anfangen zu diffen und zu fummeln.

Muss man nicht, denn vorgesehen ist laut Doku, dass eine Versionsnummer mitübertragen wird. Das Service-Plugin weiß also, dass eine alte Schnittstelle verwendet wird.

Zitat von mini73

Ich möchte mich auch eher an die Plugin-Entwickler richten.

Wo ist der Vorteil für Plugin-Entwickler? Den einzigen Vorteil, den ich bisher mitbekommen habe, war "die anderen machen es auch so".

Meiner Ansicht nach ist das, was du vorhast, eine grundlegende Umdefinierung der Service-Schnittstelle. Bisher ist jedes Plugin für sich selbst und kann ohne Existenz eines anderen Plugins (oder Bestandteilen davon) mit allen möglichen Service-Schnittstellen gebaut werden. Was du vorhast sind harte Abhängigkeiten zwischen Plugins. Ein einmal ohne "avards" gebautes Plugin kann diese Funktion also erst dann nutzen wenn später "avards" installiert und das abhängige Plugin neu gebaut wird. Spätestens der Weg "make plugins" wird dir hier Probleme machen, denn da baut der VDR die Plugins einfach wie sie kommen. Und installiert wird da auch nichts.

Zitat von Mreimer

Spätestens der Weg "make plugins" wird dir hier Probleme machen, denn da baut der VDR die Plugins einfach wie sie kommen. Und installiert wird da auch nichts.

Schrieb ich weiter oben ja schon mal, da bräuchten dann Plugins ein include-dir Target damit das sauber funktioniert.

cu

Zitat von Keine_Ahnung

Schrieb ich weiter oben ja schon mal, da bräuchten dann Plugins ein include-dir Target damit das sauber funktioniert.

... und das müsste sich dann, abhängig ob mit "make plugins" oder abseits vom VDR gebaut, anders verhalten.

Alles in allem viele offene Fragen und faktisch eine komplette Umdefinierung der Idee hinter der Service-Schnittstelle inklusive "Erfinden" von harten Abhängigkeiten zwischen Plugins, die es bisher faktisch nicht gegeben hat.

Oder um Klaus zu zitieren:

Zitat von kls

Sie sollten aber nach Möglichkeit minimiert werden anstatt sie zu manifestieren!

Klaus

Ich finde, dass eine solche Änderung dermaßen weitreichende Folgen hat, dass sowas nicht hier in einem VDR-Announcethread diskutiert werden sollte.

Zitat von Mreimer

... und das müsste sich dann, abhängig ob mit "make plugins" oder abseits vom VDR gebaut, anders verhalten.

Ne, eigentlich nicht. Das muss ja nur die Plugineigenen Headerdateien (die relevanten) ins VDR include dir (was ja in allen Fällen eh definiert ist) Kopieren.

Eigentlich erweitert/kompletiert die Idee nur die vdr.pc Idee die eh hinter den neuen Makefiles stand. Aber ich habe den Eindruck die Idee kommt zu früh Ist ja rein taktisch ungünstig jetzt mit solchen Sachen zu kommen. Sind ja noch alle ganz aufgewühlt von der letzen Änderung

cu

Im Prinzip müssen die Plugins sowieso verändert werden.

#include "softhddevice_service.h"

So werden die ja nie gefunden, wenn die global sind.

z.b. in

#include "softhddevice/service.h"

Dann könnte man mit -I/usr/include/vdr die global finden, mit -I../ bei lokalen build

Edit und bei lokalen build da muß man nichts kopieren, es reicht die richtigen plugins ausgepackt zuhaben.

Johns

Hi Klaus,

offenbar besteht noch ein kleines Problem mit Plugins und den neuen MenuCategories. Anscheinend wird bei Plugins mit einem Hauptmenüeintrag teilweise (ich vermute vom VDR selbst) mcSetup als Kategorie gesetzt. Als Workaround kann man natürlich in allen betroffenen Plugins die MenuCategory (z.B. mcPlugin) selbst setzen, aber aus meiner Sicht wäre es sinnvoller, dass der VDR das selbst abfängt...falls das möglich ist. Wäre prima, wenn du dir das bei Zeit mal anschauen könntest.

Vielen Dank schonmal im Voraus...ciao Louis

Zitat von louis

Hi Klaus,

offenbar besteht noch ein kleines Problem mit Plugins und den neuen MenuCategories. Anscheinend wird bei Plugins mit einem Hauptmenüeintrag teilweise (ich vermute vom VDR selbst) mcSetup als Kategorie gesetzt. Als Workaround kann man natürlich in allen betroffenen Plugins die MenuCategory (z.B. mcPlugin) selbst setzen, aber aus meiner Sicht wäre es sinnvoller, dass der VDR das selbst abfängt...falls das möglich ist.

VDR setzt für ein von cMenuSetupPage abgeleitetes Menü defaultmäßig mcSetup, und sobald cMenuSetupPage::SetPlugin() aufgerufen wird, wird es auf mcPluginSetup gesetzt.
Alles andere muß das Plugin schon selber machen.
Leiten denn diese Plugins ihre Menüs von cMenuSetupPage ab?

Klaus

Zitat von kls

VDR setzt für ein von cMenuSetupPage abgeleitetes Menü defaultmäßig mcSetup, und sobald cMenuSetupPage::SetPlugin() aufgerufen wird, wird es auf mcPluginSetup gesetzt.
Alles andere muß das Plugin schon selber machen.
Leiten denn diese Plugins ihre Menüs von cMenuSetupPage ab?

Das Admin Plugin von gen2vdr z.B. leitet das Menü von cMenuSetupPage ab, SetPlugin() wird da aber nirgends aufgerufen. Das burn Plugin leitet die Menüs von cOsdMenu ab...

Ciao Louis

Zitat von louis

Das Admin Plugin von gen2vdr z.B. leitet das Menü von cMenuSetupPage ab

Dann ist es ein Setup-Menü und muß sich nicht wundern, daß mcSetup gesetzt ist.

Zitat

SetPlugin() wird da aber nirgends aufgerufen.

Das ist auch hauptsächlich für VDR selber, wenn er das Setup-Menü eines bestimmten Plugins öffnet.

Zitat

Das burn Plugin leitet die Menüs von cOsdMenu ab...

Das sollte dann das Admin Plugin entweder auch so machen, oder, falls es wirklich ein cMenuSetupPage sein soll, explizit SetMenüCategory() aufrufen und den gewünschten Wert setzen.

Klaus

Hi,

ich hatte mich eben wohl nicht klar ausgedrückt...und auch nochmal genauer geschaut Bei burn gibt es auch an einer Stelle das Problem, und dort wird auch von cMenuSetupPage abgeleitet. Also liegt genau da der Fehler...

Anscheinend gibt es dann wohl keine Möglichkeit, das im VDR abzufangen und die Plugins müssen eben dementsprechend umgestellt werden...

Ciao Louis

Zitat von kls

VDR setzt für ein von cMenuSetupPage abgeleitetes Menü defaultmäßig mcSetup, und sobald cMenuSetupPage:: SetPlugin() aufgerufen wird, wird es auf mcPluginSetup gesetzt.
Alles andere muß das Plugin schon selber machen.

Hallo Klaus,

für was ist mcSetup denn gedacht? Darf das nur für VDR-eigene Menüs benutzt werden, so dass ein Plugin, das sein Menü von cMenuSetupPage ableitet explizit eine andere (welche?) MenuCategory setzen muss? Die abgeleitete Klasse ist ja dann immer noch ein Setup-Menu, so dass mcSetup nicht falsch ist ....
Müssen Plugins jetzt generell irgendwelche MenuCategories setzen oder ist das optional?

Gruß
FireFly

Zitat von FireFly

Hallo Klaus,

für was ist mcSetup denn gedacht? Darf das nur für VDR-eigene Menüs benutzt werden, so dass ein Plugin, das sein Menü von cMenuSetupPage ableitet explizit eine andere (welche?) MenuCategory setzen muss? Die abgeleitete Klasse ist ja dann immer noch ein Setup-Menu, so dass mcSetup nicht falsch ist ....
Müssen Plugins jetzt generell irgendwelche MenuCategories setzen oder ist das optional?

"Müssen" tun sie gar nichts
Wenn ein Plugin ein Menü von cOsdMenu ableitet, dann ist die Menü-Kategorie defaultmäßig mcUnknown.
Leitet es von cMenuSetupPage ab, dann ist sie cMenuSetup, was allgemein für VDRs Setup-Menü steht, in dem es nur weitere Unter-Setup-Menüs gibt.
Das spezifische Setup-Menü eines einzelnen Plugins erhält mcPluginSetup, wenn es über cPlugin::SetupMenü() aufgerufen wird.
Erzeugt ein Plugin selber ein Setup-Menü (quasi an cPlugin::SetupMenü() vorbei), dann sollte es selber mcPluginSetup setzen.

Ein Plugin kann das entweder so akzeptieren oder selber eine passendere Kategorie setzen.

Klaus

Zitat von kasper-ls

Ich wünsche mir für den VDR2.x ein Zentrales git in dem alle Plugins enthalten sind.

Die zentrale Anlaufstelle ist eigentlich das Wiki. Hier sollte theoretisch für jedes Plugin die Dokumentation nebst aktueller Version des Plugins zu finden sein.

Für mich als Pluginentwickler hat ein zentrales git mehrere Nachteile. Ich nutze derzeit kein git, damit müsste ich mich also erst mal in git einarbeiten. Die Zeit fehlt dann wieder für die eigentliche Plugin-Entwicklung. Ich habe eine eigene Infrastruktur für die Entwicklung, die ich sehr effektiv nutzen kann. Ob das so effektiv auch mit einem zentralen Repository geht, dazu müsste ich auch erst wieder Zeit investieren. Und zu guter Letzt ist ein eigenes Repository eine gute Eigenwerbung für den Entwickler.

Mein Hauptproblem ist eigentlich nur, das diverse Plugins nicht ordentlich gepflegt und dokumentiert werden und man sich die diversen Patches zusammensuchen muss. Und dagegen hilft leider kein zentrales Repository.

Mir wäre es eigentlich wichtiger das sich ein Team finden würde, das sich etwas um die Dokumentation kümmern würde und z.B. mal alle alten und ungepflegten Plugins aus dem Wiki rausschmeissen würde und ggf. wenigstens eine englische Übersetzung zur Verfügung stellen würde.

Zitat von Ulrich Eckhardt

und z.B. mal alle alten und ungepflegten Plugins aus dem Wiki rausschmeissen würde

Halte ich für ne schlechte Idee.

Evtl. findet sich ja mal ein Dev der gerne ein bestimmtes Plugin hätte. Und ist das nicht im wiki fängt er evtl. von "0" an anstatt einfach einige Zeilen Code in einem alten zu fixen.

Ferner sind einige dieser ungepflegten Plugins in Distributionen vorhanden. Und einige werden auch noch produktiv genutzt obwohl sich nicht auf den aktuellen vdr Developer Versionen laufen. Nicht jeder spielt bei den vdr dev Versionen mit.

cu