[WIP] Refactor colors #718
Conversation
ppb/colors.py
Outdated
| import colorsys | ||
|
|
||
| @dataclass() | ||
| class Color(): |
There was a problem hiding this comment.
Do we want to call this RGB instead?
ppb/colors.py
Outdated
| return (self.red, self.green, self.blue) | ||
|
|
||
| @staticmethod | ||
| def from_hsv(hue: float, saturation: float, value: float): |
There was a problem hiding this comment.
I would rather have HSV().to_rgb()?
@pathunstrom your thoughts?
There was a problem hiding this comment.
Concerned about that approach - I think there should only be one class for color so that it is intuitive to users that that’s the class they should plug in whenever they need to use a color. Don’t want people to accidentally use an HSV color when the class is expecting an RGB color, for example.
There was a problem hiding this comment.
I decided to refactor it into an abstract base class Color, with RGBColor and HSVColor subclasses that all have a to_rgb() method that should generally be abstracted away from the user. Let me know what you think!
🚨 This is a breaking change, affecting the parameters when defining shapes and setting a scene's background color. 🚨
Addresses issue #449.
Done:
colorsmodule to represent RGB colorsShapecolors,Scenebackground color, andTextcolor to use the newColorclassColorclasscolorsNext steps: