nOpacity 0.0.3

Was haltet Ihr von dem Vorschlag die Breite von z.B. dem EPG Vorschau F2 konfigurierbar zu machen? Im Moment liegt die bei ca 35% und ich fände es praktischer wenn die breiter wäre.
Dann würde man den EPG Text in der Schriftgröße erhöhen können ohne Inhalt zu verlieren und und es passt besser da hinein.

Außerdem bei 90% 16/9 Sendungen sind die schwarzen Balken Platzverschwendung. Idee dazu wäre,
alternativ mit aktivem Video scaling auf z.b. 50% setzen und unten den überflüssigen Platz für die EPG Info des gewählten Eintrages zu nutzen:

Also:

---------------------------------------------------------------
|                            	                                              |                                     	                                       |
|                            	                                              |                                                                            	|
|      EPG Liste      	|                                         |
|                            	|              TV Bild           	|
|                            	|                                         |
|                            	|                                         |
|------------------------------------------------- ------------|
|                   	EPG Info                                    |
|                                                                      	|
--------------------------------------------------------------

Verständlich? Und noch in der Größe alles einstellbar das ganze ...
Ich werde das dann als Featurewunsch einstellen, wenn die Idee Anklang findet.

Zitat von louis

torsten: die Breite des schmalen Menüs ist schon konfigurierbar (Unter "VDR Menü" die Option "Breite der schmalen Menüleiste").

Aber vielleicht wäre es möglich eine getrennte Einstellung für die Breite bei Main Menu und EPG Liste zu haben. Da die Texte doch schon recht Lang sind.

rookie

Zitat von louis

Um die Event ID herauszufinden, damit man die Detailinfos erhalten könnte, müsste man den VDR patchen oder anderweilig fummeln, das wäre aber nicht wirklich zuträglich für die Performance, insb. beim schnellen scrollen durch die Liste

Performanceprobleme beim srollen könnte man vermeiden, indem man die event ID erst verzögert anzeigt und während der Verzögerungsphase auch keine Abfrage erzeugt. Denn während des Scrollens braucht man das nicht zu aktualisieren, aber sobald man auf einem Eintrag stehen bleibt, z.b. nach 0,5s
bekämst Du die event ID nicht wenn Du eine gleiche Abfrage wie bei der Taste "i" machst? Das funktioniert ja bereits an der Stelle, nur dass halt kein Fenster sich mit den Detailinfos öffnet, sondern dass der Platz unten im Bild genutzt wird.
Wenn dafür wirklich ein Patchen erforderlich wäre, würde dies natürlich wenig sinnvoll sein, Da stimme ich Dir auch zu.

Leider sieht die Strichzeichnung sehr dürftig aus. Sie sollte nur die Einteilung des Bildschirms verdeutlichen.

Zitat von louis

Bist du dir da sicher? Was heisst "wesentlich stabiler"? Sorry für die Nachfrage, aber nach meinem Verständnis kann dein Patch nichts mit dem Absturz zu tun haben...

Wesentlich stabiler bezieht sich hauptsächlich auf den Shutdown, der bei mir immer gecrashed hat. Besser wurde es beim Abbrechen des Shutdowns. Aber du hast recht, so funktioniert es noch nicht ganz. Das Problem beim Runterfahren sind die Countdownmeldungen vom vdr. Sobald sie bei "wird in 0:00 Minuten runterfahren" angelangt sind, wird sofort eine NULL-Message hinterhergeschoben, normalerweise kommt so eine NULL-Meldung nur, wenn nach 5 Sekunden oder so die letzte Meldung vom OSD entfernt werden soll. Die NULL-Meldung führt in skins.c zur Zerstörung des Message-Objekts, dann ist aber bei aktivem Fading der Thread noch mit der 0:00-Meldung aktiv. Deshalb hänge ich einen aktualisierten Patch an, wo der Thread vor der Zerstörung der pixmap gecancelt wird.

Zitat von Siedu

Hi Ingo,

[off Topic an]
Ich will ja nicht meckern, aber der 1. Advent ist morgen
[off Topic aus]

Gruß SieDu

Manche sind halt ihrer Zeit weit voraus.

Moin!

Ich hab mir die Geschichte mit dem Fade-Thread noch nicht angesehen... Aber warum startet und stoppt ihr den denn, wenn das so Probleme bereitet?
Kann der nicht einfach schlafen, bis der nächste Fade gebraucht wird? Man könnte ihn mit cCondWait etc. entsprechend ausrüsten. Am besten aber mit einem Timeout bzw. beim Beenden des vdr muss der Thread natürlich schon geschlossen werden.

Nur mal so als Denkanstoß, hab leider gerade keine Zeit, das mal selbst zu testen.

Lars.

Zur Ergänzung zum Cancel:
Soweit ich den Ablauf in thread.c verstehe, heißt Cancel(-1) running auf falsch zu setzen, was mit Running() abgefragt werden kann im Action-Loop. Weiter wird mit dem Thread nichts gemacht, der muss sich schon selber beenden. Bei Cancel() = Cancel(0) wird zusätzlich ein pthread_cancel auf den Thread abgesetzt. Deshalb habe ich Cancel(2) verwendet, da wird nach dem Setzen des running-Flags maximal 2 Sekunden gewartet, ob der thread sich beendet hat und alle 10 ms der Status überprüft, bevor der Thread abgeschossen wird. Einen eigenen Loop um den Cancel zu bauen, ist m.E. nicht sinnvoll, weil immer nach dem 1. Durchlauf Running() falsch ist.