MainMenuHooks Patch

Aus der Readme des MainMenuhook Patch

Zitat

* Authors:
Tobias Grimm <vdr at e-tobi dot net>
Martin Prochnow <nordlicht at martins-kabuff dot de>
Frank Schmirler <vdrdev at schmirler dot de>
Christian Wieninger <cwieninger at gmx dot de>

[...]

Note that a plugin *should* offer a setup option which allows the user
to enable or disable the replacement. "Disabled" would be a reasonable
default setting. By testing for define MAINMENUHOOKSVERSNUM, a plugin
can leave the setup option out at compiletime.

[...]

Feel free to ship this patch along with your plugin. However if you
think you need to modify the patch, we'd encourage you to contact the
authors first or at least use a service id which differs in more than
just the version number.

Alles anzeigen

Ich würde die Autoren kontaktieren und die Service ID in jedem Fall auf 1.1 hochsetzen. Der Patch sollte dann auch bei epgsearch und extrecmenu, ExtP etc. verwendet werden.

LG

Joachim

Da cOsdObject die Basisklasse von cOsdMenu ist, ist die neue Version des Patches rückwärtskompatibel. Die Service-ID müsste daher nicht geändert werden. Voraussetzung ist dann aber, dass jedes Plugin das ein cOsdObject zurückliefert die MAINMENUHOOKSVERSNUM prüft. Steht diese auf 1.0, muss das Plugin den MainMenuHooks Patch ignorieren.

Bei der Alternative mit geänderter Service-ID müsste entweder VDR zukünftig zwei Serviceaufrufe machen (mit Service-ID 1.1 und wenn die nichts liefert mit Service-ID 1.0 um nicht angepasste Plugins zu erreichen) oder man macht einen Schnitt und müsste alle Plugins auf 1.1 anpassen (was sich letzlich auf das Ändern der überprüften ID beschränkt).

Ich favorisiere die erste Variante: Service-ID bleibt auf 1.0, MAINMENUHOOKSVERSNUM auf 1.1

Joe_D: Könntest du mit kls Kontakt aufnehmen, und mit ihm besprechen, wie der Patch aussehen muss, dass er in den VDR kommt?

Du weißt ja sicherlich das kls da seinen eigenen Kopf hat, wie Funktionen zu implementieren sind.

Das ganze wird sicherlich wenn überhaupt nur deutlich verändert in VDR wandern. Der erste Denkfehler des Patch ist schon, dass er das Service-Interface verwendet. Das Service-Interface ist eigentlich für Plugin-zu-Plugin Kommunikation gedacht, da diese anders nicht möglich ist. Für Patch-zu-Plugin wäre das nicht erforderlich, da können Callbacks auch direkt in die Plugin-Schnittstelle eingebaut werden.

Gruß,

Udo

Zitat

Original von schmirl
...
oder man macht einen Schnitt und müsste alle Plugins auf 1.1 anpassen (was sich letzlich auf das Ändern der überprüften ID beschränkt).

So hatte ich mir das vorgestellt. [OT] Ich verstehe auch nicht, warum manche neue Plugin-Versionen noch Kompatibilitätscode für vdr-1.4 haben. [/OT]

Zitat

Das ganze wird sicherlich wenn überhaupt nur deutlich verändert in VDR wandern. Der erste Denkfehler des Patch ist schon, dass er das Service-Interface verwendet. Das Service-Interface ist eigentlich für Plugin-zu-Plugin Kommunikation gedacht, da diese anders nicht möglich ist. Für Patch-zu-Plugin wäre das nicht erforderlich, da können Callbacks auch direkt in die Plugin-Schnittstelle eingebaut werden.

Ich finde die Lösung eigentlich für einen Patch sehr elegant, weil er sozusagen minimalinvasiv ist. Aber als Teil vom vdr sollte das sicherlich in die Plugin-API.Aber aller Wahrscheinlichkeit nach wird diese Funktion noch lange ein Patch bleiben.

LG
Joachim

Zitat

Original von Joe_D
Ich selbst habe dazu keine Zeit und (vielmehr noch!) keine Lust. Warum sollte ich viel Zeit in einen Patch investieren, wenn er schlussendlich doch nicht aufgenommen wird? Da arbeite ich lieber mit den Distributionsverwaltern zusammen, die sind kooperativer und auch pragmatischer!

Das kann man verstehen, klare Worte

Wenn alle so denken, wird das nie was. Würdest du den Patch bereinigen, wenn kls zusagt ihn zu übernehmen?

Dann würde ich eine Mail an kls schicken und ihn fragen. Bzw auf diesen Thread hinweisen.

Anbei eine Version wie sie Klaus vielleicht akzeptieren würde. Wichtig: Alle Plugins neu kompilieren! Wenn ihr beim Menüaufruf im Setup irgendeines Plugins landet, habt ihr das vergessen.

Die Notwendigkeit alle Plugins neu zu kompilieren war damals übrigens ausschlaggebend dafür, eine auf den Service-Calls basierende Variante zu entwickeln. Dass das so nie im VDR landen würde, war uns durchaus bewusst. Das ganze auf Plugin-Interface umzumünzen war aber sicher nicht der Punkt.

Aufruf in einem Plugin:

class cMyPlugin: public cPlugin {
(...)
  using cPlugin::MainMenuAction; // no warning from -Woverloaded-virtual
  virtual cOsdObject *MainMenuAction(eOSState State);
}


cOsdObject *cMyPlugin::MainMenuAction(eOSState State)  {
  if (State == osSchedule) return new cMyMenuSchedule();
  return NULL;
}

Zitat

Müssen dann nicht alle Plugins angepasst werden? Wäre es nicht sinnvoller diesen Aufruf so zu lassen wie er ist?

Ich persönlich finde es eleganter, nur eine Funktion für diesen Zweck zu haben. Für eine Übergangszeit könnte beides unterstützt werden - siehe plugin.c:

cOsdObject *cPlugin::MainMenuAction(void)
{
   return MainMenuAction(osPlugin);
}

Aber das bleibt letzlich Klaus überlassen - sofern er den Patch annimmt. Falls Klaus nichts derartiges integrieren will, sollten wir ohnehin bei der Service-Variante bleiben.

Ich werte das allgemeine Schweigen mal als Zustimmung zum Patch. Hat schon jemand Klaus angeschrieben? Weiteres anhaltendes Schweigen werte ich als Auftrag dies selbst zu tun

Ich habe Klaus bereits angeschrieben. Der ist aber momentan scheinbar nicht da. Urlaub....

Zu dem Patch selber kann ich nichts sagen. Da müssen erfahrenere Leute kommentieren.

Zitat

Ich habe Klaus bereits angeschrieben. Der ist aber momentan scheinbar nicht da. Urlaub....

Prima - danke Dir!

Zitat

Originally posted by Joe_D
Mir ist klar das der Patch nicht in den VDR aufgenommen wird. Wurde er ja zu Zeiten von 1.3.x,1.4.x,1.5.x und 1.6.x nicht, warum sollte er es nun? Ich denke eine Kontaktaufnahme ist da sinnlos.

Sinnlos sicher nicht. Zu mutmaßen, was Klaus wohl davon denkt, und dann gleich so tun, als hätte er alles abgelehnt, bringt garantiert nichts. Klaus ist nicht allwissend, und liest nicht überall mit. Ein offenes Ohr für die Community hat er aber trotzdem immer gehabt.

Zitat

Wenn man aber schon weiss das das anders zu lösen sein sollte (und das laut Mailingliste auch schon seit 2006, aufgewärmt 2007) könnte man doch mal eine Lösung dazu anbieten, oder?

Ich selbst habe dazu keine Zeit und (vielmehr noch!) keine Lust. Warum sollte ich viel Zeit in einen Patch investieren, wenn er schlussendlich doch nicht aufgenommen wird?

Zeit ist da sicher das entscheidende Problem. Ich wünschte, ich hätte so viel Zeit, wie ich gute Ideen habe. Tatsächlich schaffe ich es nicht mal 10% meiner Ideen zu realisieren.

Wenn ich mich recht erinnere, waren es hier auch die Ideen, die diesen Patch auf Eis gelegt haben: Klaus wollte glaube ich eher die gesamte Hauptmenüstruktur flexibilisieren, als punktuell einzelne Funktionen austauschen zu können. Und wie das so ist, es gibt immer etwas wichtigeres, das zu erst gemacht werden muss...

Gruß,

Udo

@ Joe_D

Zitat

Original von Joe_D
In der config.h gibt es ein define MAINMENUHOOKSVERSNUM das habe ich einfach mal auf 1.1 gesetzt. Mit dem define können neue Plugins ihr Verhalten steuern. Wird es gegen einen 1.0-gepatchten VDR kompiliert darf eben kein cOsdObject zurückgegeben werden.

Wäre es nicht besser die Versionnummer wie die übrigen Versionsnummern zu kodieren, sprich:

--- vdr-1.6.0/config.h.orig	2008-03-23 11:26:10.000000000 +0100
+++ vdr-1.6.0/config.h	2010-08-01 09:17:00.000000000 +0200
@@ -36,6 +36,8 @@
 // plugins to work with newer versions of the core VDR as long as no
 // VDR header files have changed.
 
+#define MAINMENUHOOKSVERSION "1.1.0"
+#define MAINMENUHOOKSVERSNUM 10100  // Version * 10000 + Major * 100 + Minor
+
 #define MAXPRIORITY 99
 #define MAXLIFETIME 99

Dann kann man auch vernünftig die Versionsnummer abfragen

LG

Joachim

Wie gut, das du jetzt das menuorg-Plugin ansprichst. Das setup-Plugin, bzw Patch, oder was auch immer ist nämlich der größte Verhau. Irgendso ein Aff' kam auf die Idee zich Dateien von TinyXML in den VDR zu patchen....