ich schon
eliminieren
"duck und weg"
Da kommen dann bestimmt wieder einige, die es vermissen und verteufeln dann diese Weiterentwicklung 
Teste bitte mal die Version 5
Da habe ich noch 2-3 Stellen gefunden und die Spaltenaufteilung optimiert (u.a. auch dein Screenshot 5)
So langsam müssten nun alle Stellen gefunden sein, hoffentlich 
Edit:
Anhang entfernt - neuere Version im Post #145
Irgedwie funktioniert die automatische Berechnung nichtwirklich 
Ja, das ist gar nicht so einfach, da alle Varianten abzudecken
Und die böse Zusatzinfo "verstrichen /verbleibend/Dauer" macht es nicht besser.
Das "autocalculate" solle in erster Linie verhindern, dass die Spaltenbreite zu breit ist und dann Elemente nach rechts rausgeschoben werden.
Und das klappt bisher ganz gut
@arki und @all
Ich hab mir das nochmal mit der Breite von "verstrichen/verbleibend/Dauer" angesehen.
Die Ausgabe erfolgt so:
"%d/+%d/%d min" => "100/+100/200 min"
Die Breite wird aber damit berechnet: 
"%d/+%d/%d mwidthin" (bestimmt ein "Tippfehler, wo versehentlich an die falsche Stelle in "min" das Wort "width" geschrieben wurde)
Dadurch entsteht der enorme Platzbedarf für diese Zusatzinfo, da das dann noch mit 4-stelligen Zahlen berechnet wird.
Selbst wenn ich die interne maximale Platzberechnung von 4-stellig auf 2-stellige Zahlen ändere, reicht es im Skin immer noch für 3-stellig
Hab das jetzt intern mal angepasst, so dass da jetzt eine "alltagstaugliche" Spaltenbreite rauskommt
So, dann hier noch die passende Version 6
Änderungen in 5 und 6:
- kleinere Optimierungen bei der Spaltenaufteilung in diversen Einstellungskombinationen für Progressbar und Zusatzinfo (insbesondere bei 2-zeiliger Anzeige)
- Anpassung bei der Berechnung der maximalen Spaltenbreite für "verstrichen/verbleibend/Dauer"
Edit
Anlage entfernt - aktueller Download am Ende des Threads (aktuell in Post #305)
@arki
Hier mal eine Version, wo die Berechnung für "verstrichen/verbleibend/Dauer" immer komplett bei 4-stellig liegt.
So sähe es dann aus, wenn DMM den "Fehler" korrigiert.
Ich hatte da mit Version 6 versucht, einen Zwischenwert zu finden
Schau mal, ob dir das insgesamt besser gefällt.
Damit wird die Spalte jetzt aber wieder breiter (auch für Werte, die nur 2 oder 3-stellig sind).
Edit:
Anlage entfernt - aktuelle Version ist im Post #153 zu finden
Ob mir das gefällt ist irrelevant.
Ich hab die Einstellung "Zusätzliche Sendungszeit ..." noch nie benutzt .. und werde sie auch nicht. 
Es geht doch darum alle Eventualitäten zu berücksichtigen.
So wie jetzt sieht es aber ganz manierlich aus
Das ist schon klar
Muss ja jetzt passen.
Die Frage ist ja eher, wie es jetzt bei den üblichen TV-Sendern mit 2/3-stelligen Werten aussieht.
Und dann insbesondere wenn die Progressbar am Ende und die Zeitwerte in der Mitte sind.
Könntest du da auch noch einen Screenshot machen ?
Danke
oh ! der 2. sollte eigendlich so sein
aber hier bitteschön 
Ok, bei 2-zeilig passt es ja eh, da sieht man auch gar nicht so richtig wie breit die Spalte ist.
Wenn du jetzt den Eventname in die 1. Zeile nimmst, dann sollte man auch sehen, wieviel Platz die Zeit-Spalte dann tatsächlich braucht.
Kannst du davon auch noch ein Screenshot machen ?
Meine Boxen sind gerade blockiert und kann daher nicht selbst testen
Nochmal Danke 
So eine Einstellung wird sich wohl kaum jemand antun
Ist dann hald so oder so ein Kompromis
Spaltenbreite ist hier übrigens auf 200 (HD) gesetzt.
Danke
Ja, da sieht man schon, dass die Spalte etwas unnötig breit ist.
Da ist die Frage, ob bei den wenigen Sendungen mit 4-stellig das "min" verschwindet und man sonst für die üblichen Sender eine angenehme Breite hätte.
Aber der Vollständigkeit halber und wegen der Optik sollte da nix abgeschnitten werden.
Also lasse ich das jetzt so, auch wenn die Spalte dadurch wieder etwas breiter ist. Dann gibt es zumindest keine Beschwerden, dass da was fehlt in der Anzeige.
Und wer diese Option aktiviert, ist sowieso selber schuld
So dann hier noch Version 7
Änderungen in Version 7:
Ich glaube, so langsam dürften wir fertig sein
Edit
Anlage entfernt - aktueller Download am Ende des Threads (aktuell in Post #305)
@Sven H
Du kannst doch die exakte nötige Breite eines Strings berechnen, da musst du gar keine Schätzungen machen und es wäre auch bei 4stelligen Zahlen nicht zu klein.
Du kannst die Kanalnamenbreite nicht "berechnen" die Länge ist unbegrenzt.
Dein "autocalculate" funktioniert nicht wirklich das kürzt die erste Spalte auf ein Minimum zusammen. Außerdem zerstört dein "autocalulate" die Satellitenansicht (grün) und die Provideransicht (gelb).
@dhwz
Ohne Screenshots hilft mir das leider nicht
Welchen Skin verwendest du ?
Die Breite für 4-stellig wird ja in Version 7 auch wieder exakt berechnet.
Die ist da auch nicht zu klein, sondern eher zu groß, weil man eben meist nur Events mit 3-stelligen Zahlen hat.
Wenn ich das für jeden Sender getrennt berechne (anhand des jeweiligen Strings) und ausgebe, hab ich ja kein Spaltendesign mehr
Die Kanalnamenbreite ist im Spaltenstyle eben nicht unbegrenzt.
(ist ja durch die Setup-Option festgelegt = 426 bzw. 640).
Wenn die aber fest genutzt wird, schieben sich die anderen Elemente "unsichtbar" neben die Liste.
Ich wollte mit dem autocalc ja einfach nur versuchen, die Spalten halbwegs gleichmäßig zu verteilen.
Wenn das alles nichts bringt, schmeiß ich die autocalc einfach wieder raus.
Dann muss man halt wieder mit dem Spaltenwert rumspielen.
Nein mit exakt meine ich wirklich pixelgenau auf die Länge die nötig ist wenn es auf dem Bildschirm gezeichnet wird. Ich mach dir keine Screenshots das schaffst du auch selbst.
Das mit den 640 ist mir schon klar aber dein Autocalc hat es auf ~250 gekürzt (eine sinnvolle Breite bei meinem verwendeten Skin ist 400)
Ich seh da auch kein wirklichen Sinn drin das für die Kanalnamenbreite anzuwenden, da ist der statische Wert den man selbst vorgeben kann sinnvoller, dass du die Breite für die Zusatzinfos berechnen willst ist mir schon klar das macht auch Sinn.
Also dein Autocalc macht definitiv das Gegenteil von gleichmäßig aufteilen, mal ganz zu Schweigen von den Einflüssen auf die anderen Menüs wo es gar nichts verändern dürfte.
PS: Mal kleiner Tipp um über den Tellerrand zuschauen, wie ich das im MP gemacht habe, auch wenn vermutlich etwas ungewöhnlich. Ich ermittle die vorhanden Breite der kompletten Liste und dann weiß ich auch wie ich sie (sinnvoll) aufzuteilen habe.
Tut mir Leid.
Aber bei den hier genutzten Skins kann ich deine Probleme mit autocalc nicht nachvollziehen.
Deshalb hab ich ja nach den Screenshots gefragt bzw. welchen Skin du nutzt.
Der Code zur Berechnung der exakten Breite ist ja immer nur in der jeweiligen Zeile der Kanalliste.
Da kann man ja noch nicht wissen, welcher jetzt der längste String der Liste wird, oder was meinst du ?
Deshalb hat DMM ja an der Stelle einfach den maxmimal längsten Strings verwendet, um die exakte pixelgenau Breite zu berechnen.
Aber eben nicht für die maximale Breite aller vorhandenen Einträge, sondern für den Extremfall.
maxTimeValue = 9999
textTpl = "%d/+%d/%d min" % (maxTimeValue, maxTimeValue, maxTimeValue)
addtimedisplayWidth = self._calcTextWidth(textTpl, font=self.additionalInfoFont, size=eSize(self.getDesktopWith() / 3, 0))Ich hab auch nicht gesagt dass das einfach so geht, du müsstest die max. Länge für das komplette Bouquet vorab ermitteln.
9999 ist meiner Meinung nach eh etwas übertrieben die max. Eventlänge beträgt normalerweise 1440 Minuten. Da ist der String auch schonmal kürzer (je nach verwendeter Schriftart).
Ah, ok.
Dann müsste man in der Liste "alle Sender" aber tausende Einträge durchrechnen.
Ich könnte mir vorstellen, dass das ne Weile dauert
Naja für alle muss man das ja nicht unbedingt so machen.
Ein normales Bouquet wird wohl nicht so viele Einträge enthalten dass die Performance einbricht.
