VDR Portal

Hi,

Quoted

... muss eigentlich ein OSD-Provider geschrieben werden.

Hm, also meiner Ansicht nach wäre das zu weit "low-level".
Früher unter DOS hat man Menüs meist in den Bildspeicher geschrieben und dann die Seite umgeschaltet. Damit geht dann zwar Grafik, aber jeder Bezug zu logischen Strukturen ist verloren. Ok, das war vor Deiner Zeit - egal.

Ich denke, man sollte früher ansetzen.

Wenn ich jetzt von einem Großteil der Menüseiten ausgehe, dann ist die Seite aufgeteilt in n Spalten und m Zeilen.
Dann gibt es noch die Information, ob eine Zeile auswählbar ist und welche Zeile die aktuelle ist.
Daraus müsste sich doch eine "portable" Menüstruktur erstellen lassen, die auch z.B. per JSon o.ä. übertragbar wäre.
Gut, manche Plugins wie "burn" oder "femon" könnten damit noch nicht dargestellt werden.

... aber vielleicht ließe sich auf einer solchen Menüstruktur dann für unterschiedliche Devices jeweils ein OSD-Provider erstellen?

Ein Plugin würde dann nicht mehr aktiv zeichnen, sondern lediglich die Datenstruktur bereitstellen. Für Plugins ala Recording-Menü und/oder DVD-Switch müsste dann noch eine Hierarchie unterstützt werden. Aber ich denke, das wäre mit rel. einfachem API möglich.
Damit würde sicher einiges flexibler werden und jeder OSD-Provider könnte selbst entscheiden, wo er wann wie optimiert.

Eine gute Vorlage hierzu wäre das Common-Navigator-Framework von Eclipse.
Das ist auch eine einzige Hierarchie, die von Plugins erweitert werden kann, ohne dass das Plugin, welches die Inhalte liefert, wissen muss, was wann wie gezeichnet wird.
Das komplette Framework zu portieren ist sicher viel zu komplex, aber in die Richtung zu denken wäre sicher kein Fehler.

Gruß Gero

Moin moin,

Quoted

... , hab aber dann doch schon >20 Jahre Programmiererfahrung

Hey, wollte Dir nicht auf die Füße treten! Ich schätze Dich sehr, sonst hätte ich überhaupt nicht in Deinem Fred geschrieben.
Sollte einfach ein Augenzwinkern über Dein (geringes) Alter sein.

Quoted

Das ist mit momentan "zu viel". ;-)

OK, das ist natürlich ein sehr gewichtiger Grund.

... und ich stimme Dir zu, dass so eine skizzierte Radikalkur nicht zu machen ist.
Wenn man wirklich alte Zöpfe loswerden will, dann geht das nur mit "sanfter Migration" - sprich: man macht das neue zusätzlich (Stück für Stück) - und erst wenn's zufriedenstellend funzt, werden die alten Zöpfe abgeschnitten (man könnte dem neuen Menü ja einen eigenen Hotkey verpassen).

Es gibt nicht viele Konzepte, die mich so spontan begeistert haben, wie das CNF.
Wenn man es übertragen würde - das Menü könnte man ja auch als Baumstruktur ansehen, von der jeweils nur ein kleiner Teil angezeigt wird.

Für den Fall, dass Dir das CNF nicht bekannt ist, skizzier ich es mal kurz:

Es gibt ein Wurzelelement (root oder hier Hauptmenü), welches im Container (z.B. OSD) angezeigt wird.
Dann gibt es einen Content-Provider, der immer wenn der Container Daten braucht, gefragt wird, ob es Kinder von dem Wurzelelement gibt.
Plugins können nun selbst Content-Provider anmelden und dabei noch angeben, bei welchem Typ von "Menüeintrag" sie gefragt werden wollen (der Sinn ist der, dass Menüeinträge von unterschiedlichem Typ sein können, um die Anzahl der zu fragenden Content-Provider gering zu halten)
Der Container, bzw. sein Controller hält die Liste der Provider mit den Abhängigkeiten.
Wird nun ein Menüpunkt aktiviert (z.B. Enter auf dem Eintrag), dann wird in der Liste der Content-Provider geschaut, ob einer für den Typ des aktivierten Menüeintrags registriert wurde. Wenn ja, wird dieser gefragt, ob der Menüeintrag Kinder hat. Wenn ja, wird nach der Liste der Kindelemente gefragt. Als Fallback dient immer der Content-Provider des Hauptmenüs.
Falls ein Menüeintrag keine Kinder hat, könnte der Content-Provider eine entsprechende Aktion auslösen.
Wenn man dann noch das Konzept des Selection-Providers dazu nimmt, könnte ein solcher Selection-Provider den aktiven Menüeintrag jeweils z.B. per DBus veröffentlichen.

Für die Datenstruktur könnte ich mir folgendes vorstellen:
Es gibt Menü-Zellen

• Typ
  
• editierbar [J/N]
  
• Inhalt
  

und Menü-Elemente (die Zeilen)

• Array von Menü-Zellen
  
• wenn Array nicht NULL-terminiert, Anzahl der Zellen
  
• Typ des Menü-Elements
  
• Menü-Aktion (Funktions-Zeiger)
  
• auswählbar [J/N]
  
• änderbar [J/N]
  

dementsprechend hat dann eine Menüseite eine Liste von Tabulatoren (kann je nach Device unterschiedlich sein) und eine Anzahl von Platzhaltern, in denen Menü-Elemente angezeigt werden können. Die Tabulatoren könnte man evtl. mit dem Content-Provider abstimmen, sodass der Content-Provider seine Wunsch-Tabulatoren angibt, die der Menü-Controller aber deviceabhängig überschreiben kann.
Da bei C++-Anwendungen ja alles in Silikon gegossen wird, könnte der "Typ" textuell im Menü-Element hinterlegt werden, sodass jedes Plugin einen eigenen Menütyp haben kann. Gibt es mehrere Content-Provider zum gleichen Menütyp, werden die Menüelemente unterschiedlicher Plugins zusammen geführt (eine Liste - z.B. oberste Ebene Hauptmenü).
Zell-Editoren gehören zur Kernfunktionalität des VDRs und kein Plugin kann/soll/muss sich um das Editieren von Daten kümmern. Hier müsste man noch festlegen, wann und wie Änderungen committed werden.

Ich denke, mit einem solchen Aufbau ließe sich ein Menü sowohl für OSD, alsauch für Webseiten aufbereiten, inclusive Editiermöglichkeiten.

Gruß Gero

Quoted from "mini73"

Es gibt viele Leute, die tolle Ideen haben, die muss ich nicht alle selbst entwickeln.

Das OSD komplett aus dem VDR lösen , Es gehen erstmal die Plugins nicht mehr? Kollateralschaden, duck und wech.

Gerald

Hi,

Quoted

Im vdr ist es ja fast so schon drin

Naja - nicht wirklich. Da muss man schon alle 4 Augen zudrücken, um da ne Ähnlichkeit zu entdecken.

Weiß nicht ob es noch so ist, als ich vor längerem mal den einen oder anderen Quältext anschaute, sah ich überall den Tastaturswitch.
Ist natürlich suboptimal, wenn jeder das gleiche immer wieder schreiben muss.

Quoted

Dafür zeichnet es beim Verstellen einen Balken ins OSD, damit man sieht, wie die Einstellung

Na, zum einen wäre das bereits ein Editor und zum anderen ist ein Slider für eine Zahl beileibe nix neues mehr.
Das könnte man durchaus in ein Standard-Control packen.

Quoted

Es gibt eine Menge Standard-Controls, aber eben nicht genug für alle, weil jedes Plugin sich da selbst etwas ausdenken können muss.

Hm, genau das sehe ich komplett anders.

Das Plugin mag bestimmen, ob ein Wert eine Zahl oder Text ist und in welchen Bereichen sie geändert werden kann (Einsatz von Validatoren).
Das Control würde ich aber dem Controller überlassen, der das Menü letztlich für die Ausgabe generiert.
Warum soll sich ein Plugin darum kümmern (müssen)?

Der eine Skin-Entwickler mag einen Slider als grafischen Drehknopf implementieren, der nächste macht den Schieber im Textmodus mit senkrechten Balken.
... und der Web-Entwickler nimmt dafür ein Control von extJS oder was auch immer - und alle Controls ändern den gleichen Wert für dasselbe Plugin.
Wenn man das Plugin von der OSD-Ausgabe entkoppelt, wird plötzlich vieles leichter und portabler.

Gruß Gero

Ich wollte hier mal an der Stelle einfach Danke sagen für deine tolle Arbeit.

Quoted from "mini73"

Falls jemand weiß, ob es ähnliche Mechanismen für systemd oder andere Init-Systeme gibt, würde ich gerne davon hören.

Was mir schon länger im Hinterkopf rumgeht wäre ein simples "ping" (halt pollen aber mit der selben Idee wie die upstart Sache). Erstmal um zu erfahren ob dbus2vdr überhaupt vorhanden ist, ferner um rauszufinden ob der VDR "läuft" (d.h. NICHT gerade startet oder runterfährt), das könnte das Ping ja auch in der Antwort mitliefern.

Die eine Anwendung für die ich mir das schon mal gewünscht hätte wäre z.B. die Script für den ACPI Power Button. Weil das übliche "wenn (ps | gep vdr) dann 'hitk power' ansonsten 'shutdown -h -P now'" ist sehr wackelig für den Moment in dem der VDR gerade startet oder sich beendet.

Und so was (die while Schleife mit dbus) ginge damit dann auch eleganter: [0.4] Aufnahmeliste wird beim Start nicht aktualisiert

cu

Quoted from "mini73"

Es gibt in dbus2vdr auch noch das Shutdown-Interface, das prüft, ob der vdr gerade herunterfahren darf,

Dazu auch nochmal kurz angemerkt.
Wobei, so wie ich das sehe lässt das die Scripte wirklich durchlaufen. Das gibt Probleme wenn Scripte tatsächlich Aktionen auslösen (z.B. bei mir die Displays ausschalten) die nicht gewünscht werden wenn der VDR dann einfach weiterläuft.
Evtl. wäre es sinnig hier einen 6. Parameter ("TEST") zu definieren (dbus2vdr ruft die halt mit "TEST" als 6. Parameter auf) so das die Scripte wissen das es jetzt nur eine Testanfrage ist.

[zum Rest dann später nen Kommentar]

cu