möglicher Fehler bei der Spaltenbreiten-Berechnung in der ServiceList für "Verstrichen / Verbleibend / Dauer"

  • @Reichi


    Im Zuge der Anpassung der ServiceList ist aufgefallen, dass die Zusatzinfo "Verstrichen / Verbleibend / Dauer" im Vergleich zu den anderen Varianten extrem viel Platz als Breite beansprucht.
    Optisch fast doppelt so viel als tatsächlich nötig.


    Bei der Untersuchung des Phänomens ist mir dann aufgefallen, dass für die Breitenberechnung ein anderer Formatstring als für die Anzeige verwendet wird:


    Code
    addtimedisplay = "%d/+%d/%d min"  % (elapsed, remain, duration)
    textTpl = "%d/+%d/%d mwidthin"  % (maxTimeValue, maxTimeValue, maxTimeValue)

    Ich vermute mal, dass da beim Programmieren versehentlich das Wort "width" in das Wort "min" gerutscht ist :grinning_squinting_face:


    Selbst wenn es meine angepasste ServiceList nicht ins Image schaffen sollte und es tatsächlich auch ein Fehler ist, könnt ihr das ja schonmal anpassen :thumbs_up:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Stimmt, da wird trotzdem immer auf bigPicons gestellt :winking_face:


    Schuld ist folgender Code:
    http://git.opendreambox.org/?p…dcfc5ea86805f95573d85#l62


    Code
    if self.piconpath.getIndex() > 0:
           config.usage.configselection_bigpicons.value = True
      else:
           config.usage.configselection_bigpicons.value = False

    Als man später die "/data"-Einträge dazu genommen hat, hat man einfach vergessen, diesen Code anzupassen :winking_face:


    mit dieser Änderung geht es auch mit dem Eintrag "/data/picon_50x30"

    Code
    if self.piconpath.getIndex() in (1,3):
           config.usage.configselection_bigpicons.value = True
      else:
           config.usage.configselection_bigpicons.value = False


    Man kann auch if self.piconpath.value.endswith("/picon/") verwenden :winking_face:


    In die weiterentwickelte ServiceList (konkret in der ChannelSelectionDisplaySettings.py) hab ich es schon integriert :winking_face:
    Ich hab mich dabei für die Variante mit "endswith" entschieden, falls später noch weitere Pfade dazukommen sollten.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    2 Mal editiert, zuletzt von Sven H ()

  • bin nicht sicher, ob das endswith("/picon/") immer problemlos funktioniert... koennte der pfad nicht auch mit "/picon" enden?
    ich wuerde os.path.basename(path) == "picon" nehmen.

  • Das sind von DMM im Code fest eingetragene Pfade in der config-Variablen, welche alle mit "/picon/" oder "/picon_50x30/"enden :winking_face:
    Also mit einem "/" am Ende. Somit kann der Pfad an dieser Stelle niemals mit "/picon" enden.


    http://git.opendreambox.org/?p…cfc5ea86805f95573d85#l151


    Nur bei der Anzeige in den Einstellungen wird der Pfad ohne "/" am Ende angezeigt :winking_face:
    Im gespeicherten Wert ist der "/" am Ende also immer mit dabei.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • ich wuerde os.path.basename(path) == "picon" nehmen.

    das wuerde mit / am ende gar nicht funktioieren... (gerade getestet)
    man muesste erst die dir mit os.path.normpath(path) vom trailing slash befreien.
    also ich mag keine dirs mit trailing slashes :smiling_face:

  • In anderen Situationen, wo der Pfad z.B. händisch durch den User angegeben wird, wäre meine obige Lösung tatsächlich wackelig, weil man ja nie weiß, ob der User den "/" am Ende setzt oder nicht.
    Da müsst man dann tatsächlich "bereinigende" Funktionen verwenden.


    Aber da die Pfade im obigen Code ja fest vorgegeben sind, sollte mit .endswith("/picon/") eigentlich nichts schief gehen :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • @arki
    Mach da mal bitte in dem anderen Thread weiter.
    Dein Screenshot passt nicht zu dem hier geposteten "Fehler".


    Ich hab da noch ne zusätzliche Änderung in der Testversion für die "alltagstaugliche" Nutzung.


    Ich hab lieber ne passende Breite für die üblichen 3-stelligen Werte :winking_face:


    Da auch für die üblichen 3-Stelligen immer die verschwenderische 4-stellige Breite zu nehmen, ist ja Platzverschwendung.
    Da wäre mir egal, ob die "min" bei ein paar Ausnahme-Sendern mit 4-stelligen Sendezeiten verschwindet :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    Einmal editiert, zuletzt von Sven H ()