gyscos
commented
6 years ago Hi!
I'm thinking about the best solution for color management.
I think a lot can be solved by using a larger palette - possibly arbitrarily large.
Let's consider an example use-case: I want to use a third-party view likew TreeView while customizing the color it uses for arrows; and I want this color to be different in a special popup I'm sometimes creating.
The TreeView will specify that it uses a specific color from the Palette for arrows - it could be Secondary, or something custom like TreeViewArrows. I'll just need to update this value in my palette to change this color.
Now, to have a different color when the TreeView is in a popup, the popup will need to specify a different TreeViewArrows color. To do this, it might copy over the MyPopupContent.TreeViewArrows value - it might actually copy over any value in MyPopupContent.*, so we can also re-define the background, or other colors.
So a first simple solution would be to allow any string as extra key in the palette.
An example toml configuration would look like:
[colors]
primary = "black"
TreeViewArrows = "red"
"MyPopupContent.TreeViewArrows" = "green"
"MyPopupContent.background" = "white"Now, a single large, flat palette of colors like this might work, but is less than ideal to use. There is no clear hierarchy between keys, apart from a common prefix. We could try to use an actual tree:
[colors]
primary = "black"
TreeViewArrows = "red"
[MyPopupContent]
TreeViewArrows = "green"
background = "white"However, it does make the structure a bit more complex: instead of something like a Map<String, Color>, we now have a more free-form structure. It probably doesn't matter so much; we're already parsing the toml table manually anyway.
The custom part of the Palette itself may end up looking like a tree:
enum PaletteValue {
Leaf(Color),
Node(HashMap<String, PaletteValue>),
}Third-party views that need more than the current 10 values could then define the extra keys they'll use as constants, so users at least don't have to write string literals.
njskalski
ssokolow
Hi,
this is going to be a little controversial: I spend a lot of time while working with Cursive in a very non-effective way trying to get desired coloring of views. Since the styling (like applying effects, using different colors from Palette) is usually determined by the code of View::draw(...) method, I am forced to either create wrappers that modify a theme to each view in separate or fork the entire view and manually modify the drawing method. That obviously increases cost of development and maintenance, especially with complex third party views.
In views I write, I decided to move away from predefined palette, and created something like a "style tree", where I just override colors with html color codes defined in JSON. If other (default, third party etc) views used similar technique, I would be able to achieve required styling very fast, in a way a little similar to CSS.
Would that be something you could consider for Cursive? If you are open to discussion I can make a design draft. I am thinking about something like this: https://github.com/njskalski/sly-editor/blob/master/src/default_settings.rs (theme part) but more streamlined. Like "cascading, json defined themes", that could be deserialized into objects via serde_json, so one can either configure in-code or via json.
I we'd agree on some format, I could help you to update the views, and fork and update some third party views, even help with maintaining.