[ANNOUNCE] OSD-Server 0.1.2 + Perl-Module

  • Hi,



    Eine neue Version von OSDServer ist verfügbar. Die neue Version fixt einen Bug mit Edit-Menüitems, der erstaunlicherweise seit VDR 1.5.11 nicht aufgefallen ist...


    Außerdem ist erstmals ein neues, experimentelles Perl-Modul dabei, das das Netzwerkprotokoll von OSDServer komplett kapselt, und ein objektorientiertes Interface zu OSDServer bereit stellt.


    Download wie üblich:
    http://www.udo-richter.de/vdr/osdserver.html



    Noch ein paar einfache Beispiele als Appetizer:


    Eine einfache Meldung in die Statuszeile von VDR bringen:

    Perl
    1. #!/usr/bin/perl
    2. use OSDServer;
    3. my $server = OSDServer->Open() or die "open";
    4. $server->Message("Hello World!");
    5. $server->Close();

    Nett, aber das kann SVDRPSend ja einfacher.


    Das kann SVDRPSend nicht mehr:

    Perl
    1. #!/usr/bin/perl
    2. use OSDServer;
    3. my $server = OSDServer->Open() or die "open";
    4. if ($server->Message("Is this easy?") eq "keyOk") {
    5. print "This is easy!\n";
    6. }
    7. $server->Close();

    Hier wird der if-Block nur durchlaufen, wenn der Benutzer die Meldung mit Ok weggedrückt hat. Damit wird die Sache schon interaktiver.


    Und um gleich mit den praktischen Beispielen weiter zu machen, hier eine einfache Texteingabe:

    Das Beispiel öffnet ein VDR-Menü mit einem Eingabe-Feld. Das Feld ist mit "Hallo Welt" vorbelegt und kann beliebig bearbeitet werden. Verlässt man das Menü mit Ok, wird der eingegebene Text ausgelesen und auf der Konsole ausgegeben.


    Bei den Beispielen im examples-Ordner ist auch demo-pm.pl, eine Version des alten Beispiel-Menüs, das bereits in den vorigen Versionen als Shellscript und Perl-Script dabei war, nur diesmal halt auch vollständig auf dem neuen Perl-Modul basierend dabei ist.


    Zumindest für Perl-Skripter ist OSDServer damit einfacher als je zuvor. Also: Überrascht mich, macht was vollkommen neues damit!



    Gruß,


    Udo

  • ... Experimentell meint genau das. :)


    Der angehängte Patch behebt einen Fehler mit $menu->GetCurrent().


    Noch ein Beispiel: Ein klassisches Auswahl-Menü:

    Das Beispiel funktioniert natürlich nur mit dem Patch. ;)


    Gruß,


    Udo

  • ah... da kommen ja die perl-coder :P
    ich habs mal kurz angetestet, und finde es echt genial. perl-bindings für vdr. finally *freu*
    allerdings werde ich in nächter zeit, wegen des mangels dieser, nix produktives damit anstellen.


    bei den anwendungen dachte ich bisher hauptsächlich an 'convert' anwendungen (vdr2divx, dvd-burn), aber z.B. auch ein lan-manager, der samba-shares anzeigt und mountet wäre ne hübsche sache.

  • OT-Post von hier:
    [ANNOUNCE] vdr-scripting 0.0.1 - proof-of-concept release


    Zitat

    Originally posted by Keine_Ahnung


    Was ich bissher vermisste (nur so als Anregung falls es gefällt):


    Ein Fenster für die simple Ausgabe von ASCII Text vermisse ich (so wie es nach der Befehlsausführung eines commands.conf Befehls kommt).
    Man könnte das zwar auch zeilenweise in ein Menü schreiben, aber dann gibts ja wieder Probleme mit dem Zeilenumbruch.


    Steht durchaus auf meiner Liste, zumal es ja eine entsprechende Klasse in VDR dafür gibt, die auch die commands.conf Ausgabe anzeigt.


    Zitat

    Und aus dem Bereich "wäre nett das zu habe" wäre es praktisch zu erfahlen wie breit eine Textzeile eigendlich ist (egal ob Pixel, Punkt oder was auch immer).


    Dazu dann eine Möglichkeit zu erfahren wie breit eine Zeichenkette ist.
    Das wäre z.B. für grafische Fortschrittbalken ganz nett. Dann müsste man nicht mit ausprobierten Konstanten arbeiten und die Scripte wären nicht so abhängig vom eigenen System.


    Für Menüs ist das leider nicht so einfach, da die Darstellung Skin-Sache ist, und auch ein VDR-Plugin nicht so ohne weiteres an diese Information kommt. Als Extrem-Beispiel sei hier skincurses auf der Textkonsole genannt.


    Zitat

    Habe ich mich wohl unglücklich ausgedrückt. Ich meinte, das Script kann den OSDServer nur fragen und dann reagieren. Der OSDServer selber kann nicht auf Ereignisse reagieren indem es dann entsprechend Funktionem vom Script aufruft.


    Nun, es reagiert darauf mit dem Zurückkehren vom sleepevent-Befehl. So lange das Skript sich immer mit sleepevent schlafen legt, kann osdserver entsprechende Aktionen auslösen. Für die Perl-Bindings könnte man mal darüber nachdenken, ob es einen eleganten Weg gibt, direkt Callback-Funktionen an Events zu binden, das könnte angenehm komfortabel sein.


    Zitat

    Wobei das für die OSD Sache ja auch vollkommen OK ist. Nur weitere Funktionen (z.B. beim Housekeeping irgendwas machen, beim VDR Start irgendwas machen) liessen sich auf diese Weise wohl nicht realisieren.


    Housekeeping darf das Skript alleine machen. Sleepevent hat absichtlich eine Timeout-Option, damit das Skript nicht ewig blockiert wird.




    Gruß,


    Udo

  • Zitat

    Originally posted by Urig


    Für Menüs ist das leider nicht so einfach, da die Darstellung Skin-Sache ist, und auch ein VDR-Plugin nicht so ohne weiteres an diese Information kommt.


    Aha, hatte schon vermutet das es nicht so einfach ist ;)


    Aber evtl. wäre es generell sinnvoll wenn die Skin-Plugins sowas mal zu Verfügung stellen.
    Irgendwie fällt es ja schon auf das man jedes Plugin erstmal auf die eigene OSD Grösse und Schriftart einrichten muß ehe die Darstellung passt.
    Aber egal, ist ne andere Baustelle. Ist ja auch nichts was man jetzt unbeding haben müsste.



    Das mit dem ASCII Viewer auf der ToDo freut mich auf jedenfall schonmal.
    Als C Verweigerer bin ich über den OSDServer jedenfalls sehr glücklich :)


    cu

  • Hallo an alle OSDServer-User,


    Ein kleiner Fehler ist in OSDServer-0.1.2 aufgetaucht (thx @ Tobi): Die EditIntItem-Objekte liefern mit GetValue ihr Ergebnis nicht wie dokumentiert mit einem 500er Return-Code zurück, sondern mit einem 600er. Das Problem ist leicht behoben:



    Die Frage ist: Soll ich das in der nächsten Version stillschweigend ändern (bricht evtl. die Kompatibilität mit existierenden Skripten), oder soll ich dafür die Protokollversion auf 0.2 anheben und das alte, falsche Verhalten für Clients beibehalten, die sich mit Protokollversion 0.1 anmelden?


    Das der Fehler erst jetzt auffällt, deutet ja eher darauf hin, dass EditIntItem's bisher nicht genutzt wurden...


    Gruß,


    Udo

  • hallo,


    erstmal vielen dank fuer die arbeit an diesem plugin...
    ...ich denke ich habe noch einen kleinen bug gefunden (hab aber noch nicht in den code gekuckt).


    das loeschen des 1 items funktioniert nicht:



    das loeschen des item2 und item3 objects funktioniert ohne probleme.



    gruesse
    herbsl