Py3status: py3.get_color_names_list() is naive

Created on 29 Aug 2018  路  4Comments  路  Source: ultrabug/py3status

This function should be fixed so it give accurate results. Currently it uses a poor method to find the colors. It needs to be done by the formatter parser

bug

Most helpful comment

  • self.py3.get_color_placeholders_list might be more accurate... similar to self.py3.get_control_placeholders_list. Maybe it's a little too long too.

  • self.py3.get_placeholders_list(self.format, color_names_only=True) might be more accurate too.

    • 1: Get a list of color names... for thresholds usage.
    • 2: Get a list of color + placeholder names... for post_config_hook usage.

      • pomodoro PR waits on this or self.py3.list_contains that checks a combined list.

self.py3.get_colors_list is misleading because I don't want color hex for good, bad, degraded, lime, deepskyblue, etc. I want color placeholder names, but not css color names.

self.py3.get_color_names_list optionally can have an argument to add hex codes, css color names, special color names, etc to the set too. I just have no use for those.

All 4 comments

  • self.py3.get_color_placeholders_list might be more accurate... similar to self.py3.get_control_placeholders_list. Maybe it's a little too long too.

  • self.py3.get_placeholders_list(self.format, color_names_only=True) might be more accurate too.

    • 1: Get a list of color names... for thresholds usage.
    • 2: Get a list of color + placeholder names... for post_config_hook usage.

      • pomodoro PR waits on this or self.py3.list_contains that checks a combined list.

self.py3.get_colors_list is misleading because I don't want color hex for good, bad, degraded, lime, deepskyblue, etc. I want color placeholder names, but not css color names.

self.py3.get_color_names_list optionally can have an argument to add hex codes, css color names, special color names, etc to the set too. I just have no use for those.

I know I was missing in action for a long time but this is why it is good to not merge your own code - it allows us to think things through and get the best outcome, even if it can add time which initially is very frustrating.

I'm happy to sometimes wait a year to get something right before merging.

Anyhow this should probably be discussed in #1472

I know I was missing in action for a long time but this is why it is good to not merge your own code

Yes, but you were not here and py3status was stale for many weeks. I was trying to clean out my PRs ( as well as some others). Some of them requires helpers because it's more efficient to start adding them in modules now before I merge them... and having users using them now too... than a year later.

I'm happy to sometimes wait a year to get something right before merging.

Yes. I don't know if you would be here soon or in a year. Hence me merging things to close many issues and pull requests as I can with your absence. I think this helper is very cool too! :sunglasses:

Closed via #1778.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

claiire picture claiire  路  4Comments

mxmilkiib picture mxmilkiib  路  3Comments

ghost picture ghost  路  6Comments

CorruptCommit picture CorruptCommit  路  5Comments

maximbaz picture maximbaz  路  7Comments