[ANNOUNCE] VDR developer version 1.7.27

Zitat von Kron

Hallo

Wollte seit längeren mal wieder aktiv was am VDR machen und einen eigenen Skin basteln.

Dabei ist mir im VDR Code folgendes aufgefallen:
skins.h

Code

/*TODO
  virtual void SetItem(const cEvent *Event, int Index, bool Current, bool Selectable, bool NowNext???, bool Schedule???);
  virtual void SetItem(const cTimer *Timer, int Index, bool Current, bool Selectable);
  virtual void SetItem(const cChannel *Channel, int Index, bool Current, bool Selectable);
  virtual void SetItem(const cRecording *Recording, int Index, bool Current, bool Selectable);
  --> false: call SetItem(text)
  */

Wie man unschwer erkennen kann steht das auf der TODO Liste.
Wann kann man so ganz grob mit einer Umsetzung rechnen ? Oder im gibt es im Moment wichtigeres ?
Kann man bei der Umsetzung helfen wenn ja wie und was müsste alles geändert werden?

Wäre cool wenn die Funktionen umgesetzt werden würden vor allem Recordings so kann man schon viel mehr Infos im Skin anzeigen lassen.

Alles anzeigen

Hab' mich erst gestern dazu entschlossen, das fallenzulassen, weil es zu viel Aufwand ist.

Klaus

Könntest du dann wenigstens die Theme-Schnittstelle so erweitern, dass ein Theme irgendwie mitgeteilt bekommt, welches Menü es darstellen soll? Es gibt bereits Ansätze wie man die Menüs "aufhübschen" kann, wenn man die vom VDR gelieferten Strings parst und dann zusammen mit kleinen Icons dazwischen neu zusammensetzt. So ein Mechanismus wäre erheblich weniger fehlerträchtig, wenn man sich 100%ig auf das ankommende String-Format einstellen könnte. Soll heißen: Wenn man wüsste wo man sich befindet.

Zitat von Mreimer

Könntest du dann wenigstens die Theme-Schnittstelle so erweitern, dass ein Theme irgendwie mitgeteilt bekommt, welches Menü es darstellen soll? Es gibt bereits Ansätze wie man die Menüs "aufhübschen" kann, wenn man die vom VDR gelieferten Strings parst und dann zusammen mit kleinen Icons dazwischen neu zusammensetzt. So ein Mechanismus wäre erheblich weniger fehlerträchtig, wenn man sich 100%ig auf das ankommende String-Format einstellen könnte. Soll heißen: Wenn man wüsste wo man sich befindet.

In Version 1.7.28 wird es folgendes geben:

enum eMenuCategory { mcUnknown = 0, mcMain, mcSchedule, mcChannel, mcTimer, mcRecording, mcPlugin, mcSetup, mcCommand, mcEvent, mcText, mcFolder, mcCam };


class cSkinDisplayMenu : public cSkinDisplay {
  ...
  eMenuCategory MenuCategory(void) const { return menuCategory; }
       ///< Returns the menu category, set by a previous call to SetMenuCategory().
  virtual void SetMenuCategory(eMenuCategory MenuCategory);
       ///< Sets the current menu category. This allows skins to handle known
       ///< types of menus in different ways, for instance by displaying icons
       ///< or special decorations.
       ///< A derived class can reimplement this function to be informed of any
       ///< changes in the menu category. If it does, it shall call the base class
       ///< function in order to set the members accordingly for later calls to the
       ///< MenuCategory() function.

Klaus

Schade das du die Funktionen nicht mehr verwirklichen möchtest......
Kann man dich auch nicht überzeugen wenn ich mal Versuche eine Funktion z.B. "virtual void SetItem(const cRecording *Recording, int Index, bool Current, bool Selectable);" zu integrieren und dir einen Patch zeige ?
Dann kannst ja immer noch sagen so nicht oder was man verbessern könnte.

Gruß Sebastian

Zitat von Kron

Schade das du die Funktionen nicht mehr verwirklichen möchtest......
Kann man dich auch nicht überzeugen wenn ich mal Versuche eine Funktion z.B. "virtual void SetItem(const cRecording *Recording, int Index, bool Current, bool Selectable);" zu integrieren und dir einen Patch zeige ?
Dann kannst ja immer noch sagen so nicht oder was man verbessern könnte.

Ich war schon auf halbem Weg, das einzubauen (allerdings nicht als SetItem() sondern als SetItemEvent() etc, wg. "hidden member functions"), aber dann hat sich mehr und mehr gezeigt, daß auf diese Weise einige Informationen, die in menu.c noch vorhanden sind, nicht so einfach an die Skin übergeben werden können.

Klaus

Gibt es eine Möglichkeit im Menu an das *cRecording dran zu kommen? Ich hatte schon mal dran gedacht, die HD-Aufnahmen mit einem Symbol zu kennzeichnen, aber Strings parsen um den passenden cRecording-Eintrag zu finden wäre dann doch übers Ziel hinausgeschossen.

Das skinclassic-0.0.3 Plugin läßt sich mit vdr-1.7.27 nicht kompilieren.

Zitat

symbols/teletext.xpm:23:30: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
symbols/teletext.xpm:23:30: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
symbols/teletext.xpm:23:30: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
symbols/teletext.xpm:23:30: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
../../../include/vdr/skins.h:149:16: warning: ‘virtual void cSkinDisplayMenu::SetScrollbar(int, int)’ was hidden [-Woverloaded-virtual]
skinclassic.c:247:8: warning: by ‘void cSkinKlassicDisplayMenu::SetScrollbar()’ [-Woverloaded-virtual]
../../../include/vdr/recording.h: In member function ‘virtual void cSkinKlassicDisplayMenu::SetRecording(const cRecording*)’:
../../../include/vdr/recording.h:106:10: error: ‘time_t cRecording::start’ is private
skinclassic.c:464:59: error: within this context
../../../include/vdr/recording.h:106:10: error: ‘time_t cRecording::start’ is private
skinclassic.c:464:90: error: within this context
skinclassic.c: At global scope:
skinclassic.c:57:1: warning: ‘clrMessageInfoFg’ defined but not used [-Wunused-variable]
skinclassic.c:58:1: warning: ‘clrMessageInfoBg’ defined but not used [-Wunused-variable]
skinclassic.c:59:1: warning: ‘clrMessageWarningFg’ defined but not used [-Wunused-variable]
skinclassic.c:60:1: warning: ‘clrMessageWarningBg’ defined but not used [-Wunused-variable]
skinclassic.c:61:1: warning: ‘clrMessageErrorFg’ defined but not used [-Wunused-variable]
skinclassic.c:62:1: warning: ‘clrMessageErrorBg’ defined but not used [-Wunused-variable]
make[1]: *** [skinclassic.o] Error 1
make[1]: Leaving directory `/usr/local/src/vdr-1.7.27/PLUGINS/src/skinclassic-0.0.3'

Alles anzeigen

Hat jemand eine Idee wie man das richtig ändert ohne das private im vdr selbst aufzuheben?

cu gromit

@grommit: Da hast Du was falsch kopiert: das skinclassic liegt in den Original VDR-Sourcen im VDR-Verzeichnis, nicht unter Plugins. Dort steht dann auch "Start()" anstatt "::start"

Zitat von FireFly

Gibt es eine Möglichkeit im Menu an das *cRecording dran zu kommen? Ich hatte schon mal dran gedacht, die HD-Aufnahmen mit einem Symbol zu kennzeichnen, aber Strings parsen um den passenden cRecording-Eintrag zu finden wäre dann doch übers Ziel hinausgeschossen.

Das Problem ist, daß in menu.c z.B. in cMenuScheduleItem::Update() der String zusammengebaut wird und per SetText() dem cOsdItem übergeben wird. cOsdItem wiederum ruft in seinen Display-Funktionen displayMenu->SetItem() mit eben diesem Text auf.
cOsdItem müsste nun auch noch einen Pointer auf das zugrundeliegende Object (cEvent, cChannel, cTimer bzw. cRecording) haben, den es dann an das displayMenu mit dem entsprechenden Aufruf weitergeben kann. Der String müsste aber auf jeden Fall aufbereitet werden, weil ja im Vorfeld noch nicht bekannt ist, ob die konkret verwendete Skin ihn nicht vielleicht doch lieber haben möchte als das Objekt.
Und der 'channel', der z.B. in cMenuScheduleItem::Update() bereits bekannt ist, müsste im Plugin auch erst wieder geholt werden. Ebenso müsste auch das 'withDate' Flag durchgereicht werden und so weiter. Irgendwann wurde mir das dann einfach zu viel...

Klaus

FireFly
Ich habe das hier eingesetzt:

http://rsync16.de.gentoo.org/f…vdr-skinclassic-0.0.3.tgz

was eine Erweiterung des klassischen Skins ist der dem vdr beileigt, zumindest hatte ich das
so verstanden (siehe http://www.vdr-wiki.de/wiki/index.php/Skinclassic-plugin )

Da ich eine 2MB FF Karte habe stößt die bei vielen Skins schnell an die OSD Speicher Grenzen....

cu gromit

Zitat von kls

Der String müsste aber auf jeden Fall aufbereitet werden, weil ja im Vorfeld noch nicht bekannt ist, ob die konkret verwendete Skin ihn nicht vielleicht doch lieber haben möchte als das Objekt.

An das selbst-Aufbereiten des Strings hatte ich nicht gedacht, sondern nur daran, dass man zusätzliche Infos aus cRecording holen könnte.

gromit: das ist aber schlechter Stil (des Autors) ein VDR-Standard-Skin gepatched unter gleichem Namen bereitzustellen! Du kannst im VDR-Quelltext in skinclassic.c nachsehen, wie das Plugin geändert werden muss. Grundsätzlich muss das Member "start" durch die Funktion cRecording->Start() ersetzt werden.

Zitat von kls

Das Problem ist, daß in menu.c z.B. in cMenuScheduleItem::Update() der String zusammengebaut wird und per SetText() dem cOsdItem übergeben wird. cOsdItem wiederum ruft in seinen Display-Funktionen displayMenu->SetItem() mit eben diesem Text auf.
cOsdItem müsste nun auch noch einen Pointer auf das zugrundeliegende Object (cEvent, cChannel, cTimer bzw. cRecording) haben, den es dann an das displayMenu mit dem entsprechenden Aufruf weitergeben kann. Der String müsste aber auf jeden Fall aufbereitet werden, weil ja im Vorfeld noch nicht bekannt ist, ob die konkret verwendete Skin ihn nicht vielleicht doch lieber haben möchte als das Objekt.
Und der 'channel', der z.B. in cMenuScheduleItem::Update() bereits bekannt ist, müsste im Plugin auch erst wieder geholt werden. Ebenso müsste auch das 'withDate' Flag durchgereicht werden und so weiter. Irgendwann wurde mir das dann einfach zu viel...

Klaus

Habe mir vorhin auch mal den Code an geschaut und bin zu dem selben Ergebnis gekommen. Man weiß halt nicht was der Skin haben möchte, also müsste man halt immer alles Parallel machen und den Code so erweitern....
Macht recht viel Arbeit aber mal sehen vielleicht habe ich nachher Lust, eine Funktion zu bearbeiten mal sehen was raus kommt. Man könnte damit zumindest im HD Bereich viel mehr mit den Skins machen-

Gruß Sebastian

So ich habe noch ein Problem, ich kann aber nicht sagen seit welcher Version.

Und zwar wenn ich eine Aufnahme schneide, dann aus der Aufnahme rausgehe und eine andere starte, passiert erstmal gar nichts. Sobald der Schnitt fertig ist, läuft die Aufnahme los.

System wie in Signatur, allerdings unnötigerweise noch mcli-Sammlung draufgepatcht. Ich teste das morgen mal ohne Patches, allerdings wäre es nett, wenn jemand anderes das mal ausprobieren könnte.

Danke.

Edit: Vergesst es... Ich habe den VDR komplett ohne Patches durchkompiliert und plötzlich funktioniert es.

... overpatched ...

Das kommt davon, wenn man sich ein Build-Skript schreibt und Patches einfach drinstehen lässt, die man schon ewig nicht mehr braucht.

Hi,

mal ne blöde Frage, hat irgendwer das disable double EPG-Patch für den vdr 1.7.27 angepasst? Wäre super!! Ohne ist externes EPG "schwierig"!

Danke und Gruß

Toxic

Was macht der denn?

ich nutze das noepg-plugin zusammen mit einem externen EPG.

Der mischt das EPG und sorgt für Fehlerbehebung. Fand ich immer ganz cool!

Nachdem der VDR da jetzt ne Schnittstelle für hat wird vermutlich niemand mehr Lust haben den Patch weiterzupflegen. Ist sinnvoller diese Funktion in die Plugins für externes EPG zu verlagern.

cu

Hm, habe versucht das jetzt mit meinen äußerst begrenzten C-Kenntnissen reinzufummeln, aber ich glaube da hat sich wirklich zu viel geändert... Also noepg-Plugin?!