Issue in ServiceList.py

  • Hi,


    I would like to report a formatting issue in the Service List file, located at:

    Code
    /usr/lib/enigma2/python/Components/ServiceList.py

    Issue:

    Within the _buildOptionEntryAddTimeDisplay function, the time display template is defined as:

    Code
    textTpl = "00:00 - 00:000"

    However, the time is actually formatted using:

    Code
    "%02d:%02d - %02d:%02d" % (beginTime[3], beginTime[4], endTime[3], endTime[4])

    This means both the start and end times should be displayed as two-digit values (HH:MM). The extra digit in the end time template ("00:000") is therefore incorrect.


    Impact:

    • The incorrect template may result in inaccurate width calculations.
    • It might also lead to inconsistent UI appearance.


    Suggested fix:

    Change the template to:

    Code
    textTpl = "00:00 - 00:00"

    This change will ensure that the display width is correctly calculated based on the actual time format.


    Best regards.

  • I think it is not an issue.

    The textTpl is used to calculate the needed addtimedisplayWidth to show the addtimedisplay-Text.

    With "00:00 - 00:000" you can set the max. of width for all values (begin - end time) to get the best calculated needed width.

    Perhaps the width was sometimes to small, so the textTpl was added by a next 0. :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One + Two mit DP AIO - OE2.6

    Edited 3 times, last by Sven H ().

  • Thank you for your comment! I agree with you that the purpose of textTpl is to calculate the required width for the addtimedisplay text correctly, and the idea of using a string to determine the maximum width makes sense.

    However, I think "00:00 - 00:000" might not be the best choice here, as it doesn’t fully match the actual format of addtimedisplay, which is "HH:MM - HH:MM". Using "00:00 - 00:00" would be sufficient and more accurate to reflect the real format, or perhaps "88:88 - 88:88" if we want to ensure the maximum possible width with proportional fonts.

  • Have you tested your changes to "00:00 - 00:00" ?

    I think not :winking_face:


    If i change the textTpl to "00:00 - 00:00" the width for the time-text is to small.

    (screenshots from Default-FHD skin)

  • Maybe this was my mistake, as I tested these changes on an image that already had some differences from the original image. :winking_face:


    However, I found a solution for the original Images that maintains the correct "HH:MM - HH:MM" format while ensuring the text is fully displayed. Instead of relying solely on "00:00 - 00:000" to increase the width, I modified the code in the _buildOptionEntryAddTimeDisplay function as follows:

    With this modification:

    • I used "00:00 - 00:00" as the standard textTpl to match the actual "HH:MM - HH:MM" format.
    • I added a minimum width constraint (max(addtimedisplayWidth, 180)) to ensure enough space for the full text, regardless of font size or screen resolution.

    I tested this solution, and it works well on the original Image without truncating the text, while keeping the correct format. This way, we achieve the goal of calculating the optimal width without needing extra zeros like "00:000", which might not reflect the expected format.


    You might also consider making some adjustments to "buildOptionEntry" to ensure it aligns well with this modification.

    Edited once, last by Andro1 ().

  • Calculate with fix width like 180 is not a good idea, because this value is not equal in all skin resolutions and fonts.


    So the developer has use the "00:00 - 00:000" as a solution and it is not an issue.

    You don't have to frantically look for another solution, because the code works.

    Its not a bug, its a feature. :winking_face:

    This code is using since 9 years and i have not heard, that this has a problem in using the box.


    You must not search for all "errors", which not really are errors.

    A real error is, when i have problems in using the box.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One + Two mit DP AIO - OE2.6