Updating bigclock with RGB color pickers #668
Conversation
joeyhoer
requested review from
betterengineering,
rohansingh and
matslina
as code owners
joeyhoer
force-pushed
the
bigclock-rgb-color
branch
from
49e9aa2
to
4400b16
Compare
…st of colors for full customizability
joeyhoer
force-pushed
the
bigclock-rgb-color
branch
from
4400b16
to
cb30e16
Compare
There was a problem hiding this comment.
Hey! It's a bummer we don't have a color picker widget yet. I think everyone at Tidbyt agrees we'd like to address that, but there's a lot of other stuff in flight so I'm not sure when we'll get it done. =(
In the meantime, a change like this makes sense if people are asking for more detailed control. I am wondering though what you think about e.g. placing these RGB selectors behind a toggle or something like that? Basically offer easy to use color selectors up top, with the option of doing a more fine grained tuning for power users. Big clock is pretty popular, and we have a large number of not-very-technical users for whom I suspect the RGB selectors will be very confusing. WDYT?
| @@ -150,8 +162,18 @@ def main(config): | |||
| is_24_hour_format = config.bool("is_24_hour_format", DEFAULT_IS_24_HOUR_FORMAT) | |||
| has_leading_zero = config.bool("has_leading_zero", DEFAULT_HAS_LEADING_ZERO) | |||
| has_flashing_seperator = config.bool("has_flashing_seperator", DEFAULT_HAS_FLASHING_SEPERATOR) | |||
| color_daytime = config.get("color_daytime", DEFAULT_COLOR_DAYTIME) | |||
There was a problem hiding this comment.
A bit over half of all installations of big-clock are using a non-default value for color_daytime or color_nighttime. It would be great if we could make this change backwards compatible so that these installations continue to function as before.
There was a problem hiding this comment.
I was also a bit concerned about backwards compatibility, and I agree that most users will find the RGB values confusing. I was actually considering using HSL instead, as that's a little easier to understand, but ultimately decided against it.
I could not think of a way to support both the selector and the default color, unless the user types in a hex value — but again, that would require input validation.
I believe the best solution here is a color picker schema.
There was a problem hiding this comment.
Color picker schema would be great. It's just a matter of finding the time to build it out. Lot of other priorities as always. =(
For backwards compatibility, the app should still receive the color_daytime parameter for existing installations (even when it's been removed from get_schema()), so it'd just be a matter of checking for that field first (with the same default) and then letting the new RGB parameters override it.
There was a problem hiding this comment.
Receive via a config.get("color_daytime"?
What happens in the future, when you implement a color picker, and then we need to revert back to color_daytime and people have the RGB values stored?
There was a problem hiding this comment.
Yes, it should still be passed the same way for older installations.
When there's a colorpicker field, you'd need to introduce a new field ID, like colors_daytime_rgb, to keep backwards compatibility.
There was a problem hiding this comment.
Since the RGB values are not intuitive, and there would be more complexity switching back and forth between the various methods to achieve backwards compatibility, I think it would be best to wait until there is an official colorpicker schema.
I'm going to close the pull request, and hopefully we can come back to this at a later date. Thanks!
Updating bigclock to use RGB color values rather than a predefined list of colors for full customizability.
In absence of an official color picker schema solution (#39), I've added RGB color values as a dropdown to allow for full color customizability rather than forcing users to select from a predefined list of colors. A number schema solution (#298) would also be superior to a drop down, but those tickets were closed due to inactivity.
I considered using a text field an having the user input a HEX string value for the color, but I decided that input validation would be too difficult. The "number selector" dropdown approach (while inelegant from a configuration UI perspective) ensures that the color will always be valid.