Idee Skindesigner als neues Graphtft ?

Das geht doch schon fast alles?!

Ausserdem wird noch aktiv an graphtftng entwickelt, wenn Du Feature-Requests hast, dann ab zu vdr-developer.

prinzipiell ist das gtft kein OSD einfach weil der vdr nur ein OSD unterstützt und darüber hinaus die Infos ja auch fließen müssen wenn das OSD geschlossen ist.

Daher ist das gtft vom Prinzip her schon etwas anders.

Christian

Moin,

dass der Skindesigner direkt eine Art "OSD" für ein zweites Display ausgibt, ist nicht möglich, da der VDR eben wie schon geschrieben aktuell nur ein OSD / einen Skin zu einer Zeit darstellen kann.

Ich weiß aktuell gar nicht, wie graphTFT genau arbeitet bzw. wie es genau die Ausgabe macht...vielleicht könnte man da auch die geplante "erweiterte Plugin Schnittstelle" für den Skindesigner nutzen, die ich implementieren möchte, damit Plugins die ihr OSD komplett selbst zeichnen (wie z.B. der TVGuide), auch Skindesigner Templates dafür benutzen können. Schaumer mal...

Ciao Louis

Letztendlich kann sich mittlerweile jedes Programm an den Daten des vdr über dbus2vdr bzw. restfulapi bedienen. Ihr müsst euch nur vom vdr-OSD lösen und ein eigenständiges Programm entwickeln, das ein eigenes Menü darstellt und auch eine eigene Steuerung mitbringt. Da ist man viel flexibler, als dem vdr jetzt ein Multi-OSD beibringen zu wollen.

So ähnlich macht graphtftng das ja auch, es hängt nur noch zu sehr am vdr-OSD.

Lars

und der vdr muss dafür gepatched werden

bei restfulapi hat man den Vorteil das man fast völlig frei bei der Umsetzung ist.

nur wie die daten per xml übergeben werden ist schon pervers als das mein Prof. gesehen hat schüttelte der nur mit dem Kopf

aber zum Glück gibts ja auch JSON

bastel mit da auch grade was universelles aber die Zeit fehlt aktuell leider

wenn man das frosted glass auch einfach in einem vdr skin umsetzen könnte wäre es schon cool aber hab mir das mal angeschaut und mir nur gedacht nööö sooo wichtig isses mir dann doch nicht

(wobei es auch gut performance kostet obwohl es könnte auch am livetv im hintergrund liegen ^^/ ich denke mal ein webbrowser ist da nicht soo optimiert

Zitat von Moorviper

nur wie die daten per xml übergeben werden ist schon pervers als das mein Prof. gesehen hat schüttelte der nur mit dem Kopf

Prof? *g* Bist du noch so naiv zu glauben, dass ein Prof von irgendwas ne Ahnung geschweige denn Praxiserfahrung hat?

Ciao Louis

Zitat von louis

Prof? *g* Bist du noch so naiv zu glauben, dass ein Prof von irgendwas ne Ahnung geschweige denn Praxiserfahrung hat?

+1

Ist Open Source, er darf sich gerne einbringen...

Das Ding ist historisch gewachsen, mit der Erfahrung bisher würde es heutzutage, wenn man neu anfangen würde, natürlich ganz anders aussehen. Hinterher ist man immer schlauer...

Lars.

Zitat

Prof? *g* Bist du noch so naiv zu glauben, dass ein Prof von irgendwas ne Ahnung geschweige denn Praxiserfahrung hat?

da gibts unterschiede

die Spanne zwischen vollpfosten und genie ist in fulda sehr groß

ja deswegen schrieb ich ja zum Glück gibts JSON

xml finde ich persönlich eh doof wegen dem overhead

und joah alles um zu stellen ist bei bestehenden anwendungen die es Nutzen immer blöd

Zitat von mini73

Das Ding ist historisch gewachsen, mit der Erfahrung bisher würde es heutzutage, wenn man neu anfangen würde, natürlich ganz anders aussehen. Hinterher ist man immer schlauer...

Am XML-Teil bin ich zumindest unschuldig

Gerald

Zitat von gda

Am XML-Teil bin ich zumindest unschuldig

Ich zum Glück auch...

Lars.

bei restfulapi gabs auch immer noch diese push pull Problematik - der vdr patch ist mW auch dazu da das der vdr die infos pushed

Christian

Da komm ich dann wieder zu dbus2vdr zurück. Wenn zwei Programme auf der gleichen Kiste laufen, lassen sich da wunderbar Signale verschicken...

Das cStatus-Interface des vdr kann man ja z.B. schon als DBus-Signal empfangen, z.B. Kanalwechsel, Aufnahmestart usw.

Lars.