Posts by Ramirez

Quote from Saman

Moin,

ich bastel mir zur Zeit an einem neuen Theme.
Dabei ist mir aufgefallen, das in 'cNopacityTimer::Render' 'pixmapBackground' mit Schwarz gefüllt wird (auf dem Screenshot ist das schon clrTransparent)
Gibt es einen speziellen Grund warum da nicht Transparent oder MenuBack verwendet wird?
Das gleiche gibt es auch im tvguide in 'cTimeLine::drawTimeline' bei timelineBack.

Ganz toll fände ich auch seperate Farben für die Fortschirttsbalken in der Programmansicht und beim Kanalwechsel.

Für meinen neuen Theme benötige ich es zwar nicht mehr, es intressiert mich aber doch, warum der Vorschlag von hier nicht angenommen wurde. Damit ändert sich doch für die alten Themes nichts mehr.

Da sich der neue Theme zu meinem vorherígen vom Setup schon sehr unterscheidet: wie kann ich am einfachsten (und am besten aus dem OSD) für verschiedene Themes sepeate Setups einspielen?

Gruß

Display More

Ich wollte ja auch meine Timer durchscheinend haben und war deswegen auch schon an der Stelle im Code. Das mit dem schwarz hatte ich auch nicht verstanden.

Mit der Diskussion über die Fortschrittsbalken in der Programmübersicht machts Du aber wieder mal ein Faß auf. Konsquent gesehen bräuchte man ja dann insgesamt vier Farbsets, jeweils eben xxxBar, xxxBarBack und xxxBarBlend.
Einmal für die Kanalanzeige und zwei in der Programmübersicht, einmal für gewähltes Item und eben normal. Wenn man es übertreiben will, müsste man sogar noch den Rahmen festlegen

Das hat louis ja neu eingeführt, ich habe für clrProgressBar und clrMenuItemHigh die gleiche Farbe. Daher ist mir das auch gleich aufgefallen, dass es nicht 100% optimal ist. Durch den Rahmen kann man es noch einigermaßen gut aus der Ferne erkennen.

By the way, nettes Theme

Ich hänge den Patch einfach mal hier an. Ist halt wirklich eine Haudrauf Lösung. Einfach einen boolschen Parameter reingepackt und überall außer den betroffenen Stelle false reingereicht.

Quote from Programie

Ja gut ich kann ja auch erstmal eine Installation mit ESXi machen und wenn es mir nicht gefaellt kann ich immer noch alles ohne Virtualisierung machen.

Eigentlich sollten ja alle aktuellen CPUs die notwendigen Virtualisierungstechnologien unterstuetzen, oder?

Nein, dem ist leider nicht so. Du musst schon darauf achten, dass die CPU/Mothterboard Kombination VT-d unterstützt!

Quote from Programie

Aber wie sieht es mit den Platten fuer den Fileserver aus? Wenn dann sollte die Fileserver-VM die Platten vollstaendig verwalten. Also ohne irgendwelche virtuellen Festplatten sondern direkt irgendwie die S-ATA Devices in die VM reichen. Geht das?

Mein ESXi muss hier noch ganz andere Dinge schaffen, da lasse ich mal andere zu dem Thema Stromsparen ran. Für meinen Teil bin ich mit dem Stromverbrauch sehr zufrieden. Aber ein Dual Xeon mit 12 Cores braucht halt etwas mehr Saft

Da es hier ja um eine Heimlösung geht, kann ich Dir nur sagen, dass das nicht von VMWare supportet wird, aber einwandfrei hier läuft. Mein virtualisierter Fileserver hat eine virtuelle Disk für das OS und die Platten mit den Shares sind direkt eingemountet. Man muss das zwar auf der Commandline und nicht im vSphere Client machenl, aber es läuft einwandfrei (das UI mag das nur für iSCSI Platten machen).

Wenn der finale Stand erreicht ist, kann ich mal eine Doku aufsetzen. Vorher macht es ja keinen Sinn. Im Gegensatz zu Sourcecode müsste man ja bei den Screenshots immer neu anfangen.

Was mich hier bei den VDR Theme Files vermisse ist, dass man keine Konstanten definieren kann, wie Du es im Source tust. Mal Buttons und Messages herausgenommen nutze ich eine Kombination aus 5 Farben, die ich je nach Anzeigeelement unterschiedlich kombinieren will. Wenn man nun eine Farbe ersetzen will, so muss man es an zig stellen tun. Ein einfaches search and replace könnte da eben auch stellen erwischen, die man nicht will.

Bezüglich tvscraper Darsteller Bilder:
Ist mir schon klar, dass irgendwann abgeschnitten werden muss. Momentan ist es halt bei fast jedem Namen.

Eine perfekte Lösung wäre wohl nur in das Menü einen Button mit "Darsteller" zu packen und würde eine zusätzlich aufrufbare Liste bedeuten. Da nOpacity aber nur ein Skin ist, müsste das ja in den tvscraper Code.

So ein Riesen-Faß wollte ich jetzt nicht aufmachen. Eigentlich würde es reichen, wenn ein oder zwei weniger in der Zeile wären. Das müsste ich mal sehen, wie das aussieht. Ein Darsteller pro Zeile sähe wirklich doof aus.

So auch mal auf die letzte GIT Version upgedatet. Wie immer Danke für die tolle Arbeit

Ist schon ein merkwürdiger Effekt, wenn man in seinem Theme einige Farben nicht hat. War richtig psychadelisch nach dem Update

Wir sind nun schon bei Kleinigkeiten angekommen:
- clrReplayHighlightIcon kann rausfliegen, wird ja nicht mehr verwendet
- In de_DE.po Zeile 390 ist ein kleiner Typo: "Ordner Icon Größe" sollte es wohl heißen

Wärst Du noch so lieb das mit den Timern einzubauen. Die Schrift ist jetzt schön, aber ich würde gerne die Farben für aktive Timer definieren.

Momentan gilt für inaktive Timer:
Hintergrund clrTimersBack, Header in clrMenuFontTimersHeader und Text in clrMenuFontTimers.

Für aktive Timer:
Hintergrund clrDiskAlert, Header in clrMenuFontTimersHeader und Text in clrMenuFontTimers.

Die jeweiligen Blend Versionen habe ich nicht aufgeführt.

Ich persönlich unterscheide die Farbe für Header und den Text gar nicht. Hier hätte mir auch ein Wert gereicht. Aber ein clrMenuFontActiveTimers (und damit dann ein clrMenuFontActiveTimersHeader) wären noch i-Tüpfelchen. Sauber wäre natürlich auch ein clrActiveTimersBack anstatt einen anderen Wert zu nutzen. Da ich die Disk nicht anzeige, wäre mir das aber auch wieder egal.

Vielleicht bin ich auch nur zu blöd die Einstellung zu finden, aber inzwischen habe ich mich an diese schicke Liste der Darsteller meiner Aufzeichnungen mit tvscraper gewöhnt. Aufgrund der Breite werden die Namen, wenn die Darsteller nicht gerade Jon Doe heißen, fast immer abgeschnitten. Ich würde lieber ein wenig weiter nach unten scrollen, wenn ich dafür die Information sehen könnte.

Schaut gut aus.

Der Code sieht nun wie gewünscht aus und was noch viel besser ist, nOpacity und extrecmenu laufen zusammen

Ich wußte gar nicht, dass in yaVDR auch die Plugins gepatcht werden. Wenn dem so ist, könntest Du auch mal folgende Änderung
(http://projects.vdr-developer.org/issues/1224) am lcdproc Plugin einpflegen?

Jedes Mal, wenn der dist-upgrade das Plugin neu zieht, muss ich immer das

(LcdSetup.ShowSubtitle) &&

rausschmeißen. Ist definitiv ein Fehler, denn mit der Änderung läuft es bei mir nun schon über ein halbes Jahr unproblematisch.

Wenn Du magst, erstelle ich auch einen korrekten Diff

Folgender Bug ist bereits für das Plugin gemeldet:
http://projects.vdr-developer.org/issues/1371

Der in dem Bugreport genannte Patch ist bereits in yaVDR - testing eingepflegt mit einem kleinen Fehler:
nOpacity pre 1.0.0

In mymenurecordings.c muss es int savedlevel=Level; heißen.

Quote from louis

Ramirez: hm, dann ist der Patch für extrecmenu wohl noch nicht 100% ok. Der Autor hatte ja damals auch "quick & dirty" dazu geschrieben. Das Problem liegt auf jeden Fall darin, dass extrecmenu den Level der Aufnahmen bei verschachtelten Verzeichnissen nicht korrekt setzt. Wenn du Lust hast, kannst du ja mal schauen, ob du den Patch besser hinbekommst

Ciao Louis

So ich habe mir das jetzt wirklich mal selbst angeschaut. In der Tat bekommt nOpacity ganz komische Werte für Level und zeigt dann natürlich Murks an.

Ich habe dann wirklich selber eine Lösung gecodet, die die Klasse um einen recordingLevel erweitert und diesen dann einfach beim Anzeigen verwendet. Das hat funktioniert

Obwohl ich die im Patch skizzierte Lösung unschöner finde, müsste sie eigentlich auch gehen. Der Fehler ist im yaVDR Paket, wo der Patch nicht korrekt übernommen wurde:
Anstelle von

int savedlevel=level;

müsste ein

int savedlevel=Level;

stehen.

Ich habe noch nie verstanden, warum sich Leute mit case sensitiven Sprachen so geißeln, dass sie Variablen nur in Groß-/Kleinschreibung unterscheiden. Hat ewig gedauert den Fehler zu sehen.

Am saubersten wäre es wohl, wenn der Code zum Titel zusammenbauen in
einer eigenen Methode wäre und dort auch eine eigene lokale Variable
verwendet werden würde und nicht einfach level vergewaltigt werden
würde.

Ich mach mal ne Meldung im yaVDR Teil und kann bezüglich diesen Threads nur sagen, dass es cool aussieht in nopacity

Quote from louis

Hi,

hast du auch Urlaub?

Warum sollte ich dich steinigen...benutze einfach Hi,

hast du auch Urlaub?

Warum sollte ich dich steinigen...benutze einfach diesen Patch.

Ciao Louis

Display More

Ne, habe nie Urlaub als Freiberufler. Aber muss gerade UI Programmierung machen. Da habe ich eigentlich nie Lust drauf. Backend Logik gerne, aber UI

Also ich wollte gerade meinen VDR patchen, habe jetzt aber gesehen das bei yaVDR Testing der Patch bereits integriert ist. Ich bin gerade nicht in der Lage mir zusammenzureimen, wann es nicht geht und wann es geht. Mit dem Patch habe ich Ordner, wo es geht und manche wo es nicht geht. Ganz wirr wird es, wenn es in den Ordnern noch Unterordner gibt (yaVDR mountet per avahi meine anderen VDR´s ins Aufnahmeverzeichnis, daher habe ich hier Ordner/Unterordner).

Quote from winni

Hi,

Ramirez: Kannst Du bitte hier mal Deine menu.c vom VDR reinhängen? Die dürfte ja mit vdr.epgsearch-exttimeredit-0.0.2.diff gepatched sein.
Ich frag nur, weil es dort nämlich eigentlich durchaus Tests gäbe, die gelöschte Timer abfangen.

Davon unabhängig sollte es aber eigentlich schon klappen dem Konstruktor die Info mitzugeben. Der Patch von oben ruft das TimerEditMenü von epgsearch über das Service-Interface auf, d.h. wenn man in epgsearch.c in Zeile 257 die Info mitgibt sollte das schon reichen. Ich vermute, dass sonst niemand das TimerEditMenü über das Service-Interface ruft. Zur Not kann man da ja noch was feilen. Vielleicht kannst Du das ja mal in Deinem bisherigen Patch testen.

kls: O-Ton ML
"There may be a plugin interface later that can do things
like this, but until then this is not recommended ;-)"
Das war 2004, vielleicht kommt das Interface ja doch noch
Aber ich weiß, gibt wichtigeres.

Gruß,
winni

Display More

Ich verwende yaVDR und da kommt der Patch einfach mit.

Ein apt-get source vdr liefert als Ausgabe unter anderem:

...
dpkg-source: Information: opt-67_epgsearch-exttimeredit-0.0.2.patch wird angewandt
...

Sicherheitshalber habe ich sie auch mal angehängt.

Ich habe die von Dir skizzierte Lösung mal umgesetzt und den Konstruktor von

cMenuMyEditTimer(cTimer *Timer, bool New, const cEvent* event, const cChannel* forcechannel=NULL);

nach

cMenuMyEditTimer(cTimer *Timer, bool New, bool returnToTimersAfterDeletion, const cEvent* event, const cChannel* forcechannel=NULL);

geändert und in Folge dessen an der von Dir genannten Stelle true und an allen anderen Stellen false reingereicht.
Damit kann nun an der betreffenden Stelle wahlweise den passenden Wert zurückgeben.

Sieht alles mehr nach Hack aus, aber es funktioniert wie erwartet ohne Absturz

Der Effekt ist wie erwartet etwas unschön, da er nun aus Benutzersicht nach dem Löschen immer auf den ersten Timer springt. Aber damit kann ich leben, denn
a) wie bereits erwähnt, löscht selten jemand über diesen weg
b) mir war wichtig, das niemand hier im Haus durch rumklicken einen Absturz erzeugen kann

Wahrscheinlich werde ich jetzt von louis gesteinigt, aber vielleicht weiß ja einer was da mit dem schmalen Menü und extrecmenu schiefgeht.

extrecmenu setzt ja in der aktuellen GIT Version korrekt die Kategorie. Daher erkennt nOpacity nun auch die Ausgabe als Aufzeichnungsmenü. In der breiten Ansicht hat man daher jetzt das korrekte Icon. Sonst hat sich hier nichts geändert, da ja die Ausgabe wie vorher in diesem Fall erfolgt.

Die schmale Ansicht sorgt jedoch für Probleme mit Ordnern (Aufnahmen in der obersten Ebene machen keiner Probleme).

Beispielsweise:
Ordner
- Aufnahme 1
- Aufnahme 2

Steht man auf Ordner, so kommt gescrollt nicht Ordner, sondern Ordner ~ Aufnahme 1. Also immer der komplette Pfad zur ersten Aufnahme im Ordner.

Wenn man ein bischen rumnavigiert kommt es noch zu ganz anderen komischen Seiteneffekten.

Ich weiß louis verwendet das Plugin nicht, aber es sollten doch eine Menge User hier geben. Weiß jemand was da schiefläuft und vor allem, in welchem Plugin der Fehler liegt?

Quote from Saman

Nee, das reicht leider nicht.
clrMenuScrollBarBack ist der Hintergrund der Scrollbar selber.
Im Theme auf den Fotos zB
clrMenuBorder = DD8c8c8c
clrMenuScrollBar = DD8c8c8c
clrMenuScrollBarBack = 40135474

Es geht um die Transparente Fläche (Bild 2) auf der die Scrollbar gezeichnet wird (Bild 1).
Im Code wird da clrTransparent verwendet, nach dem Patch dann Theme.Color(clrMenuBack) wie auf Bild 4 zu sehen.
Auf Bild 3 sieht du dann wieder die Scrollbar.

Display More

Achso, ich habe nur nicht mehr transparent gelesen. Wenn es clrMenuBack ist und jeder selbst (per Theme) entscheiden kann, ob er es transparent haben will oder nicht, dann ist das was ganz anderes

Also ehrlich gesagt, bin ich über den Bug auch nur deswegen gestoßen, weil ich mein Theme für nopacity und tvguide ausprobiert habe und dabei jede Menge unsinnige Timer angelegt und wieder gelöscht habegesehen habe. Wenn ich in der Timer Ansicht sowieso schon bin, dann kann ich auch mit Gelb löschen (ja, das ist auch bei epgsearch noch Löschen).

Das Löschen aus dem epgsearch eigenem TimerEditMenü nutze ich sehr oft, wenn ich die Timer in der Programmansicht editiere. Da kommt es öfters mal vor, dass ich einen Timer wieder löschen will. Dann finde ich es umständlich extra erst ins Timers Menü zu gehen, diesen wieder rauszusuchen und anschließend zu löschen. Das Löschen macht hier also absolut Sinn.

Von mir aus könnte man es auch so ändern, dass der Löschen Button nur angezeigt wird, wenn das Menü nicht aus der Timers Übersicht angezeigt wird. Was im Endeffekt dieselbe Problematik hat. Wie kann man an dieser Stelle des Codes herausfinden aus welchem Menü man aufgerufen wurde?

Quote from Saman

Moin Louis,

da solltest du sehen, was ich meine:

Äh? Ich mag den Scrollbar gerade transparent haben. Wenn man es nicht transparent haben will, sollte es doch reichen clrMenuScrollBarBack auf FFxxxxxx zu setzen und gut ist.

Als Ergebnis des Threads sehe ich hier, dass es eine wohl wirklich saubere Lösung in einer VDR vnext irgendwann mal geben wird.

Nach wie vor sehe ich als die pragmatischte Lösung an, wenn epgsearch in diesem konkreten Fall einfach osTimers zurück gibt. In allen anderen Fällen eben weiterhin osBack. Es gibt nun aber in epgsearch sehr viele Stellen, wo das EditTimerMenü instanziert wird und ich weiß leider nicht, wie man dort jeweils rauskriegen kann in welchem Menü der VDR gerade ist. Denn dann könnte man diese Information einfach an den Konstruktor weiterreichen.

@winnie: Wäre das überhaupt möglich?

Alsol ich find es schick.

Quote from mini73

Dann frage ich mich, wie es knallen kann, wenn das Edit-Menü von epgsearch im ProcessKey Timers.Del aufruft.
Wie wird denn zum aufrufenden Menü zurückgegangen? Wird das nicht noch mal neu gezeichnet bzw. mit neuen Daten gefüttert?
Vermutlich ist es immer noch das selbe Objekt, dass dann selbst seine Anzeigedaten aktualisieren muss?

Lars.

Nein, es knallt ja nicht, wenn Timers.Del aufgerufen wird.

Mal zur Vollständigkeit, der Code um den es geht:

LogFile.iSysLog("deleting timer %s", *timer->ToDescr());
		Timers.Del(timer);
		gl_timerStatusMonitor->SetConflictCheckAdvised();
		Timers.SetModified();
		return osBack;

Dieser läuft bis zum Ende durch. Soweit habe ich mich durchgehangelt.

Der Absturz kommt erst nach dem osBack ausgewertet wird. Denn dann fängt der Skin an das Timer Menü neu zu zeichnen. Hier gibt es jetzt aber ein Item, dass keinem Timer mehr zugeordnet ist => Crash.

Das Timer Menü des VDR implementiert, wie Du mich richtig hingewiesen hast, eine eigene Löschfunktion, die im Prinzip dasselbe macht und zusätzlich ein

cOsdMenu::Del(Current());

aufruft.

Daraus schließe ich, dass der Code davon ausgeht, dass dies die einzige Möglichkeit ist einen Timer zu löschen.

Und mit plain VDR stimmt das ja auch. epgsearch führt halt eine zusätzliche Möglichkeit Timer zu löschen, während das Menü im Hintergrund liegt.

Daher meine Schlußfolgerung, dass der eben erwähnte Code eben bei jeglichem Löschen stattfinden sollte.

mini73: Danke für die Erklärung. Nun verstehe ich langsam die Zusammenhänge und vor allem weiß ich jetzt, warum es beim Löschen (Gelb) aus dem Timer Menü nicht kracht. Hier wird einfach das MenuItem entfernt.

Zunächst einmal muss ich Klaus und louis zustimmen. Ein Skin sollte sich wirklich nicht um sowas kümmern. Und es crasht auch mit den VDR eigenen Skins. Nur halt nicht so oft, weil die weniger Zeit zum Zeichnen brauchen. Dadurch ergeben sich aber andere lustige Abstürze, wenn man dann etwas mit den gezeichneten Timern machen will.

Das Problem ist ja, dass im epgsearch Plugin ein Timers.Del gefolgt von einem Timers.SetModified aufgerufen wird und dies keinerlei Auswirkung auf das Timer Menü hat.

Meiner Meinung nach wäre eine saubere Implementierung, wenn sich weder epgsearch noch der Skin um diese Sache kümmern würden. Eigentlich sollte sich das VDR eigene Timer Menü um die Timer Events kümmern und im Löschen Fall das zugeordnete MenuItem entfernen.

Und nun schlagt mich

Ich bin auch eher für unten rechts, weil man doch mal die ein oder andere Aufnahme mit einem längeren Titel gibt. Je seltener gescrollt werden muss, desto besser. Finde ich zumindest.