[ANNOUNCE] [vdr] VDR developer version 1.3.7

Hi

Zitat

- Durch viele installierte Plugins wird es unübersichtlich, hier ist eine Ordnerstuktur wie bei den Aufnamen sinnvoll.
- Die Programmierer geben den Einträgen einfach z.B. den Namen 'Zusatz~Name' und dann wird ein Untermenu 'Zusatz' mit allen Plugins deren Namen mit 'Zusatz~' anfangen angezeigt

oder unterverzeichnisse im lib-dir, wo die unterverzeichnisse die submenus darstellen. So hätte das jeder selbst im Hand, wie die Menus heisen.

oder entsprechende einträge in der setup.conf, die das definieren.

das wäre auch ne möglichkeit, die ich gut finden würde

Gruß Dirk

Ich hab mir grad die skinsttng.c angeguckt, bin beeindruckt, Skins zu machen dürfte richtig Spaß machen....

Wie schaut die Sache mit dem begrenzten OSD-Speicher aus, checkt VDR da was gegen, wenn man "zu dick aufträgt", oder "geht das direkt raus" ?

Hallo !

@ Austrian Coder

Zitat

In der neuen Version hat sich viel getan.. die Changelog ist schon recht lange

Hast du schon ein Datum ???
Wäre natürlich auch schon mal an das Changelog vorab interresiert ?

Gruß Denny

Zitat

Original von s_herzog
Ich hab mir grad die skinsttng.c angeguckt, bin beeindruckt, Skins zu machen dürfte richtig Spaß machen....

Wie schaut die Sache mit dem begrenzten OSD-Speicher aus, checkt VDR da was gegen, wenn man "zu dick aufträgt", oder "geht das direkt raus" ?

Siehe osd->CanHandleAreas() bzw. osd->SetAreas().

Klaus

s_herzog: Da bin ich mal gespannt wie du das machen willst.

Nightstorm99:

Hier, das was ich bis jetzt habe:

- we are using now <linux/em8300.h> instead of "em8300.h"
- updated multichannelaudio.h/c with newest AC3overDVB-Patch-Source
- switched to new osd routines for vdr-1.3.7
- added dxr3singleton.h
- new interface to work with ffmpeg (chagned include to <avcodec.h>)
- added a lot of commments and cosmetic code cleanups
- using everywhere std::string - makes life nicer
- moved dxr3absdevice to dxr3interface
- rewritten some parts of dxr3interface
- added anti-glinsch-when-fast-forward-and-then-play-patch ;)
- killed DIAG and added a global logger, which is used only in
  a few functions and not in every like DIAG
- removed cDxr3StatusMonitor - i dont know why we need this
- cleaned out unneeded includes
- fixed memory leak in cDxr3Interface::UploadMicroCode:
  If uploading of the microcode failed, the allocated memory wasn't
  freed.

Am mpeg-basierten Menü arbeite ich gerade.

Gut Nächtle !

@ Austrian Coder

Zitat

Am mpeg-basierten Menü arbeite ich gerade.

Das klingt ja mal richtig viel versprechend. Dann dürfte man ja mehr
möglichkeiten haben als auf einer FF-Karte !!!!????!!!!

PS: Melde mich als Tester vor weg an !

Gruß Denny

Hallo Klaus,

Zitat

Original von kls
Ich kann halt nicht alles gleichzeitig machen

So war's doch auch nicht gemeint, wenn es gut werden soll braucht es eben Zeit, da müssen wir einfach etwas warten ...

Zitat

Finde ich nicht, denn dann kann man ja nicht mehr sehen, welche Version eines
bestimmten Plugins installiert ist, bzw. ob das Plugin überhaupt installiert ist.
Evtl. wäre es sinnvoll, im Setup/Plugins-Menü die gleiche Menüstruktur zu machen
wie im Hauptmenü.

... oder eine Liste der Installierten Plugins ...

Zitat

BTW: wer oder was ist der "SV"?

Mit SV... ist die Schnittstelle auf Port 2001 gemeint, den Namen wuste ich nicht genau.

Hardy

Zitat

So was's doch auch nicht gemeint, wenn es gut werden soll braucht es eben Zeit, da müssen wir einfach etwas warten ...

...das nenn ich doch mal eine Erkenntnis ... gratuliere

steffx

Hallo Dirk,

Zitat

Original von Dirk
oder unterverzeichnisse im lib-dir, wo die unterverzeichnisse die submenus darstellen. So hätte das jeder selbst im Hand, wie die Menus heisen.

Da man mehre Plugin-Verzeichnisse angeben kann wird das schlecht machbar sein.

Zitat

oder entsprechende einträge in der setup.conf, die das definieren.

Ich glaube auch, dies ist die einfachste Variante, so kann jedes Plugin so bleiben.

Hardy

Hallo steffx,

Zitat

Original von steffx
...das nenn ich doch mal eine Erkenntnis ... gratuliere

ich hatte doch schon meinen ersten Beitrag an Klaus mit:

Zitat

Vielleicht arbeitets Du schon an der einen oder anderen Lösung.

begonnen ...

Hardy

Zitat

Original von Austrian Coder
s_herzog: Da bin ich mal gespannt wie du das machen willst.

machstu kleine "beschreibungssprache" für die einzelnen Elemte des OSD?

z.B.

/etc/vdr/skinengine/skin1/menu.skn

CIRC 0,0,maxx,30,#332212
RECT 0,0,10,maxy,#332212
MWND 20,20,maxx-20,maxy-20,#332212,#FFFFFF
TIME maxx-75,0,maxx,10,#FFFFFF
SPCE maxx-200,0,maxx-80,10,#FFFFFF

wobei mir das apontan einfiel, CIRC=circle, RECT=rectangle, MWND=Menu-Bereich, TIME=Uhrzeitanzeige, SPCE=Platzanzeige

Dann müsste die entsprechende Methode im eigentlichen Skin nur diesen Wust von Datei einlesen und aufbauen, sollte doch gehn, oder nicht? (Abgesehen davon, dass die obige Idee noch einer Überarbeitung bedarf..)

Dazu natürlich noch ein Plugin, das die Skins selektierbar macht...

Zitat

Sorry, aber ich kann dir da echt nicht folgen...
Ich habe jetzt in VDR eine Plugin-Schnittstelle eingebaut, über die man das
Erscheinungsbild des OSD komplett selber implementieren kann. *NATÜRLICH*
ist das eine Programmierschnittstelle, und nicht irgend ein XML- oder was-weiß-ich
Firlefanz!

Mag sein das du mir net folgen kannst , wobei mein "flexiblere" ungluecklich
gewaehlt ist.
Ersetze es mal mit "durchsichtigere" ;).

Ich zeige mal im Groben, wie ich es gehofft haette :

Maximale Anzahl von Objekten im Code , wobei Plugins Objekte hinzufuegen koennen :
Die Aufarbeitung und Anzeige findet im Code statt.
Die Werte werden aus Themedateien ausgelesen.
Sowas ist fuer mich ne Skinengine (-> in Klammern).
So wird dann eine Themedatei ausgelesen , welche in etwa so aussieht :

visible : Anzeige ja/nein
Object : Bild,Viereck,Elipse,Kreis
filename : Dateiname wenn Bild sonst 0
x1: 1.Wert left-top (von Objekt)
x2: 2. Wert left-top (von Objekt)
x3: 1. Wert left-top (Anzeige auf OSD)
x4: 2. Wert left-top (Anzeige auf OSD)
radius: Radius/Bogen bei Kreis/ellipse,etc
color : Farbe
alpha: transparenz
...
..
etc

Objekt1:visible:Object:filename:x1:x2:x3:y4:radius:color:alpha...etc
Objekt2:visible:Object:filename:x1:x2:x3:y4:radius:color...etc
Objekt3:visible:Object:filename:x1:x2:x3:y4:radius:color...etc

Sowas inner Textdatei zu editieren ist einfach.
Da gibt es kein xml hoechstens Firlefanz aber ist einfach FUER ANWENDER.
Das ist naemlich in etwa das Plugin , worauf alle warten

Ich weiss jetzt auch net , wie oder was das OSD kann . Aber wenn die
Karte sowas wie Double-buffering o.ae. besitzt , ist das leicht "flickerfrei" zu coden. FUER C/C++-PROGRAMMIERER
Aber gibt ja auch noch andere Loesungen.
Wenn nicht , dann halt schwieriger aber fuer Anwender sind Themes
dann wesentlich einfacher zu erstellen und unmaechtig ist das nun
auch net gerade .
Meisten haben halt 80 kb OSD und 16 Farben.
Alle anderen koennen sich dann das PSone mit 20 MB Bitmaps
vollpflastern;)

Naja auch egal , ich weiss deine Arbeit schon zu schaetzen
Aber wo waere man ohne Kritik (auch wenn se fuer den einen unkonstruktiv erscheint)
Btw. sollte garkeine Kritik sein.

bye

Zitat

Original von Morone

Mag sein das du mir net folgen kannst , wobei mein "flexiblere" ungluecklich
gewaehlt ist.
Ersetze es mal mit "durchsichtigere" ;).

Ich zeige mal im Groben, wie ich es gehofft haette :

Maximale Anzahl von Objekten im Code , wobei Plugins Objekte hinzufuegen koennen :
Die Aufarbeitung und Anzeige findet im Code statt.
Die Werte werden aus Themedateien ausgelesen.
Sowas ist fuer mich ne Skinengine (-> in Klammern).
So wird dann eine Themedatei ausgelesen , welche in etwa so aussieht :

visible : Anzeige ja/nein
Object : Bild,Viereck,Elipse,Kreis
filename : Dateiname wenn Bild sonst 0
x1: 1.Wert left-top (von Objekt)
x2: 2. Wert left-top (von Objekt)
x3: 1. Wert left-top (Anzeige auf OSD)
x4: 2. Wert left-top (Anzeige auf OSD)
radius: Radius/Bogen bei Kreis/ellipse,etc
color : Farbe
alpha: transparenz
...
..
etc

Objekt1:visible:Object:filename:x1:x2:x3:y4:radius:color:alpha...etc
Objekt2:visible:Object:filename:x1:x2:x3:y4:radius:color...etc
Objekt3:visible:Object:filename:x1:x2:x3:y4:radius:color...etc

Sowas inner Textdatei zu editieren ist einfach.
Da gibt es kein xml hoechstens Firlefanz aber ist einfach FUER ANWENDER.
Das ist naemlich in etwa das Plugin , worauf alle warten

Ich weiss jetzt auch net , wie oder was das OSD kann . Aber wenn die
Karte sowas wie Double-buffering o.ae. besitzt , ist das leicht "flickerfrei" zu coden. FUER C/C++-PROGRAMMIERER
Aber gibt ja auch noch andere Loesungen.
Wenn nicht , dann halt schwieriger aber fuer Anwender sind Themes
dann wesentlich einfacher zu erstellen und unmaechtig ist das nun
auch net gerade .
Meisten haben halt 80 kb OSD und 16 Farben.
Alle anderen koennen sich dann das PSone mit 20 MB Bitmaps
vollpflastern;)

Naja auch egal , ich weiss deine Arbeit schon zu schaetzen
Aber wo waere man ohne Kritik (auch wenn se fuer den einen unkonstruktiv erscheint)
Btw. sollte garkeine Kritik sein.

bye

Alles anzeigen

Es spricht überhaupt nichts dagegen, daß jemand ein Plugin schreibt, das sowas
implementiert, wenn es das ist, was alle wollen. Nur als zentrale Schnittstelle im
VDR-Kern wäre sowas ungeeignet - da halte ich die jetzige cSkin-Schnittstelle
für wesentlich besser.

Aufbauend auf dieser Schnittstelle sollte es nicht allzu schwierig sein ein Plugin
zu schreiben, das eine über Konfigurationsdatei(en) definierbare Skin-Schnittstelle
implementiert.

Falls du sowas machen willst, beachte bitte, daß der Begriff "Theme" jetzt von VDR
für die Farbgestaltung belegt ist. Es würde nur unnötige Verwirrung stiften, wenn du
den gleichen Begriff auch noch für etwas anderes verwenden würdest

Klaus

Hi,

irgendwie verstehe ich die ganze Diskussion nicht:. Es ist doch kein Problem, ein "Firlefanz"-Plugin zu schreiben, das irgendwelche "Firlefanz"-Skin-Dateien auf die Plugin-Schnittstelle umsetzt.

Edit:
Ah ja, Klaus war da schneller.

Außerdem mal was Grundsätzliches:
Die 1.3.x ist eine Entwicklerversion. Mir gefällt überhaupt nicht, daß hier im Portal zunehmend Druck auf den/die Entwickler entsteht (sowohl, was vdr-Features angeht als auch was die Anpassung der Plugins für Version 1.3.7 betrifft).

vdr ist ein Hobby, die Leute haben ja auch noch was Anderes zu tun.
Geduld ist angesagt!

1.3.7 ist die erste Version mit Skins/Themes, und möglicherweise werden sich in den Folgeversionen noch Änderungen ergeben. Eins nach dem anderen. Der nächste Schritt wäre, erst einmal Plugins für die "Skins" zu schreiben, die es bisher als Patches gab. Dann sieht man, ob/wo noch was fehlt.

CU
Oliver

Ja,
bei einigen Frage ich mich auch, was sie erwartet haben.

Klaus wollte doch eine Schnittstelle zum OSD schaffen, damit Plugins besser darauf zugreifen können.
Auf diese Weise sollte die Möglichkeit geschaffen werden, altenative OSDs via Plugin zu realisieren, also statt Elchi-Patch jetzt ein Elchi-Plugin

Von Skins/Themes im VDR Kern war doch eigenlich nie die Rede?

Ich hab mir die Schnittstelle selbst zwar noch nicht angesehen, aber nachdem was ich hier so lese, entspricht es genau meinen Erwartungen/Vorstellungen.

Monroe

Wer macht Druck? Wenn es so erschien, das war sicher nicht gewollt...

Wäre übrigens unschön, wenn sich an der Schnittstelle was änderte....

Zitat

Hier ist einen ähnliche Entwicklung im Gange wie einst bei Linux. Der Erfinder (hier Klaus) wird zu Manager...

Vatertag ??

ich hätte da eine frage zu vps

und zwar würde mich intressiern wie das mit nur einer FF dvb karte ordentlich funktionieren kann.

vps wird doch wie teletext in der vertikalen Austastlücke des TV-Signals ausgestrahlt.
kann die dvb karte ein vps signal auf Transponder A empfangen während ich einen Kanal auf Transponder B live sehe wenn nur eine FF karte vorhanden ist?

man kann ja zb, mit nur einer FF karte, auch keinen sender aus Transponder A ansehn wenn man etwas aus Transponder B aufnimmt. oder funktioniert das mit vps anders ?

weak:

Du hast das richtig erkannt. Mehr Infos dazu gibt es in den Dokus zu 1.3.7 bzw. auch bei früheren Versionen bei denen VPS implementiert ist.