The Color Theme

[br07h3rj]

Is there an easy way of passing around lots of specific color values that I just don't know about? I feel like I'm missing something. It seems that DVUI has lots of power under the hood, but, when it comes to widgets, it only gives me handful of crayons to use and a few of them just disappeared when I updated last night!

Currently, my project is up to 37 color settings (probably 20 of which are unique colors) and the total number of settings will probably be over 100 before I'm done (and it should be possible for ALL of those settings to be different colors). To make that possible, I've been using what you guys call "overrides" for color control and re-implementing helper functions as needed (so far just for menus and tabs, but I can see a need for more).

My project runs in a full system window with a system titlebar, run on a desktop PC. It will not be an app on a phone and it will not rely on any use of a web browser. The eventual feature set that I intend for my project requires state-dependent control of all visual attributes of every instance of every widget on the screen. (I don't expect you guys to do all of that. I just want you to make it possible for me to do that.)

The big trouble I'm facing is that there are so many functions that are hard-coded to use the built-in theme system that seems very much unsuited to my use case. To be clear, I'm not complaining about the theme system. There are other use cases in which it would be convenient. The problem is that I seem to be locked into it with no other options. I can suggest design parameters, but I'm not familiar enough with dvui yet to tailor them to your approach. I just got really nervous when I saw some of my color-handling disappear. The theme system as it stands right now just doesn't seem usable for me.

Am I missing something about how to use DVUI or is this a design thing?

[RedPhoenixQ]

It seems that DVUI has lots of power under the hood, but, when it comes to widgets, it only gives me handful of crayons to use and a few of them just disappeared when I updated last night!

Sorry about that! #498 made a lot of changes to Themes and how colors are resolved from the Options and current theme. There is also a couple of known differences in appearance before and after.

I think we came to the conclusion that in #498 that most widget colors should be able to be configured through Options. Unfortunately for widgets that need two completely different sets on colors, having X amount of color-sets on dvui.Options wasn't reasonable. The compromise we reached was that these widgets use a "style" from dvui.Theme, like dvui.Theme.highlight for selected menu items.

Currently TextLayoutWidget uses dvui.Options.color_accent to override the text highlight color. We could potentially offer a style_override field on Options or on the individual widgets options, like MenuItemWidget.InitOptions could have an single override set of colors to use for highlighting instead of dvui.Theme.highlight.

It would be really helpful if you can point out which widgets, and what colors/states, need to have these override options added.

For now, you should come most of the way using the Options.color_... to override colors, or Options.style to set which theme colors are used. Maybe you can make a generic function to override the theme for a certain scope, even though that is not as nice. More examples of colors/settings that aren't configurable that you'd want to/need to be would be nice here.

[br07h3rj]

That's good to hear. Ideally, I want to be able to feed colors into each widget without touching the themes at all. I'm building my own theme system, so I don't really need or want to deal with the DVUI theme system. Even so, as long as there's a sane way of controlling all color and style assignments to a widget (no options left hard-coded and no options buried beyond hope of passing values), I can work with it. I mostly just want to be sure that DVUI is going in the direction of more control, not less control for more convenience.

Let me give a brief example of what I've been doing. This is the struct I've been using to hold attribute values for the tabs:

const Tab = struct {
    bar_padding_left : f32,
    bar_padding_top : f32,
    bar_padding_right : f32,
    bar_padding_bottom : f32,
    bar_border_thickness : f32,
    padding_left : f32,
    padding_top : f32,
    padding_right : f32,
    padding_bottom : f32,
    text_padding_left : f32,
    text_padding_top : f32,
    text_padding_right : f32,
    text_padding_bottom : f32,
    thickness : f32,
    corner_radius : f32,
    space_between : f32,
    draw_accent : bool,
    draw_close_button_background : bool,
    close_button_spacer : f32,
    close_button_padding_left : f32,
    close_button_padding_top : f32,
    close_button_padding_right : f32,
    close_button_padding_bottom : f32,
    close_button_border_thickness : f32,
    close_button_corner_radius : f32,
    color_close_button_border : ?Color,
    color_border : Color,
    color_background : ?Color,
    color_tab : ?Color,
    color_hover : ?Color,
    color_pressed : ?Color,
    color_text : ?Color,
    color_text_pressed : ?Color,
    color_inactive : ?Color,
    color_accent : Color,
    color_close_button_background : ?Color,
    color_close_button_foreground : Color,
}; var tab : Tab = undefined;

I still feel that I haven't included everything and will find a couple more options I need to add. The goal is complete themeability.

As a side note, the biggest reason I had to re-implement addTab was to give myself an option to turn off drawing the accent on focus.

(Getting rid of ColorOrName was a good move, by the way. That extra consideration was a bother.)
And I'll definitely let you know if I bump into anything I can't work around.

[RedPhoenixQ]

So, considering that Options doesn't have color_text_press, color_fill_hover, or color_fill_press anymore, is there an intended way to manually control those colors? I was using those for menus and tabs.

That might have been a mistake. I think the intent was to make Options simpler as most widgets don't use a hover/press state. These should probably also be passed in each individual widgets InitOptions I think. Higher level widgets can pass through these options to configure them

We also need to find a good solution to the "inherited styles" issue. Most higher level widgets should probably just pass through all styles to its child widgets and also make the styles available for the users child widgets. See MenuItemWidget.styles from #498

[david-vanderson]

Great! Thanks very much for blazing this trail with us.

The idea (could be wrong) with the current theme system was to find some line to separate the colors in Options from those in Theme. What I came up with was that the colors in Options are enough for a single frame (because in a single frame a widget knows if it is normal/hovered/pressed). That's enough for a button to pass those colors down to the things in the button.

We don't currently have a notion of active/inactive - do you mean something like graying out a button? Or do you mean keyboard focus?

For your case (where you want to override everything) I figured you'd have 2 options:

• use a different style from Theme (this works if you only need a few different styles)
• temporarily modify the theme before/after the widget

So the big question for you is whether temporarily modifying the theme before/after a widget is workable. Could you try that and say how it goes? Seeing code would be great if possible.

If that is super annoying, then maybe we'll have to add more colors back into Options, or figure something else out.

[david-vanderson]

Sorry - when I say "could you try that" I mean in a few examples. I'm not expecting you to overhaul your whole thing just to try it. It's just super useful to get feedback from someone who hasn't been stewing in this stuff for a long time!

[br07h3rj]

No worries. I came across that idea (resetting theme colors for individual widgets) in skimming things around here a week or two ago and I quickly came to the conclusion that it is technically possible to make that work, but it's not going to be a good solution for a few reasons.

1. Inefficiency: I intend to allow for maybe a dozen high level widgets on screen at once. Aside from adding extra lines of code, if it were ten widgets, that means the same theme color might get reset 600 times per second. Enough of that actually can bog down a program that I intend to be as light weight as possible. (I always want to be efficient enough to allow older hardware to do the job.)

2. The theme system doesn't allow enough colors to be set at once without user modification. I tend to use lots of subtle accent colors to round out appearances. This could be addressed by just adding more color options, but the naming conventions will get wonky (like recycling color_text for things that are not text).

3. And, of course, you never want a work-around to be your plan A. Design problems should be addressed with redesign. (Technical debt accumulates quickly because of things like this.)

I think you guys were on the right track when talking about higher level widgets passing attributes to their constituent widgets. What I think you need is an exhaustive list of attributes for the base widgets and then the painful part will be making each widget pass attributes to the correct constituent widget to get the right effect. I think the widgets themselves should be the challenge and not the design of the color-handling because of the theme system. To that end, I have something else I'd like to post if you'll suffer reading it.

[david-vanderson]

I agree with your worries:

1. This might be true, but needs measurement to verify, as performance is super hard to intuit these days.
2. Depends on how many more you need, can you give an example?
3. True, but we have to compromise between people who want to pick a built-in theme and never change it, and your case where you want to customize everything. This is the great challenge of library design. Hopefully we can find some way to please everybody, but different uses might require different amounts of code. Some libraries (dear imgui I believe) do all theming this way (change before and after).

You are certainly giving me a lot to think about, and it's great feedback! One thing we've run into is that the base widgets tend to grow features over time, including things that then require new colors/attributes, so we can't make an exhaustive list and call it done, there has to be some fallback mechanism.

Will read the post and think about it!

[br07h3rj]

I wrote this up last night after talking with you guys and reading more of #498. These are just ideas to be entertained. Don't shoot!

If you're interested, I know of a way you can settle this theme stuff once and for all. Like I said, I'm building my own theme system and I planned out some parameters for how I wanted that to work. I don't know if any such suggestions would be welcome, but I'd like to lay them out anyway. These are just ideas based on how I've been setting up my project. Please feel free to dismiss these as the wild ramblings of some crazy man on the internet. No worries. My idea for my theme system is for nothing about the appearance to be hard-coded or otherwise assumed, leaving all judgement calls to the user (aside from the bare minimum for consistent display purposes), aiming for an exhaustive set of attributes fully user-controlled. If dvui were to do this, it would be even better. That would make DVUI a complete toolkit approaching the likes of GTK+ and Qt, and maybe superceding them in certain ways. If this thinking were applied to DVUI, I believe it would look something like this:

User Land

	Theme Name Variable

	Calls for Widgets

DVUI

	Widgets

	Instances for Every Loaded Theme

	Theme Files

All widgets should accept raw values for all attributes.

Theme attributes should be stored and accessed as sets of these raw values.

All widgets should be written to receive one valid theme name and reference the attribute set of that theme which is loaded from files.

If no theme name is given, widgets should rely exclusively on user-provided attributes.

Every widget should assume sane defaults for every attribute left unset by the user or theme.

Users should be able to load and unload themes from User Land by providing a file name. Built-in theme aliases can be provided as an afterthought.

All attributes should be state-dependent.

Attributes

colors

paddings

margins

border sizes

corner-radii

fonts

font styles

States

normal

focused

active (fallback for the focused color when focus is stolen by another widget)

inactive

hovered

pressed

released

dragged

shadowed (indicates unavailability)

That would be 63 total attirbutes for something like a box widget. (Believe it or not, I still consider this is be a compromise that leaves out control that would cost too much in code complexity for the value of the feature, like independent control of border color on all four sides. That just wouldn't be worth it.) Then all you'd need is a simple way of allowing color aliases (e.g. .red) to get automatically translated to hex codes and that should complete the base feature set.

Complex widgets can be treated individually. I already have (almost) complete lists of attributes I care about for tabs, menus, and panes. I provided the Tabs struct above, so I'll stick the other two here just as examples of how I have been setting things up. I'm still working on building up TextEntry. (That one will have a cursor color, cursor width, and cursor height, hopefully switching to an underscore cursor in Insert mode and a block cursor or pipe cursor for normal mode, as is tradition.)

const Panes = struct {
    padding_left : f32,
    padding_top : f32,
    padding_right : f32,
    padding_bottom : f32,
    margin_left : f32,
    margin_top : f32,
    margin_right : f32,
    margin_bottom : f32,
    border_thickness : f32,
    sash_thickness : f32,
    sash_max_thickness : f32,
    sash_margin : f32,
    mouse_distance : f32,
    split_ratio_horizontal : f32, // There are three split_ratios because I'm nesting two vertical panes inside one horizontal pane.
    split_ratio_vertical_left : f32,
    split_ratio_vertical_right : f32,
    color_border : ?Color,
    color_sash : ?Color,
    color_sash_handle : ?Color, // It would be lovely if I could also have a static handle that I can define without mouse reactivity.
}; var panes : Panes = undefined;


const Menu = struct {
    bar_padding_left : f32,
    bar_padding_top : f32,
    bar_padding_right : f32,
    bar_padding_bottom : f32,
    bar_border_thickness : f32,
    padding_left : f32, // Applies to the floatingMenu.
    padding_top : f32,
    padding_right : f32,
    padding_bottom : f32,
    item_padding_left : f32,
    item_padding_top : f32,
    item_padding_right : f32,
    item_padding_bottom : f32,
    corner_top_left : f32, // Applies to the floatingMenu.
    corner_top_right : f32,
    corner_bottom_right : f32,
    corner_bottom_left : f32,
    selection_corner_radius : f32,
    item_main_margin_left : f32, // Applies only to the top level menuItems (e.g. File, Edit, View) so they can be adjusted without effecting items in floatingMenus.
    item_main_margin_top : f32,
    item_main_margin_right : f32,
    item_main_margin_bottom : f32,
    color_bar : ?Color, // Applies to the menu bar itself.
    color_background : ?Color, // Applies to floatingMenus.
    color_border : ?Color,
    color_hover : ?Color,
    color_pressed : ?Color,
    color_text : ?Color, // I was also trying to use color_text_press here but gave up on it and I was wishing that I had color_text_hover too.
}; var menu : Menu = undefined;

I think a setup like this would give all users as much or as little control as they want and nothing would be left dangling. Again, I'm just babbling about wouldn't-it-be-nice-if. I have no idea what it would take to bring dvui in line with this description and I wouldn't expect it to be well received. I would be interested to hear your thoughts about it, though.

[RedPhoenixQ]

I'm with you on the "no hardcoded values" part and to allow everything to be customizable. I do however have a different take on where the line for dvui's responsibility and the application code would be.

Just as a general thought, the Options struct is a compromise between enough configuration for most widgets and not too much to significantly confuse users or impact performance. Every single widget get an Options struct, so we should be selective about what is included there.

All widgets should accept raw values for all attributes.

Theme attributes should be stored and accessed as sets of these raw values.

I'm unsure what you mean by "raw". If you mean like hex color strings for colors and so on, I disagree as that would be a significant overhead for no gain for 90% of use cases. Most values can be translated to and from "raw" string value in the application code and dvui can provide these transformation functions, but should not require their use.

If you mean "raw structs/integers/floats" then I agree. This is effectively how dvui work currently with the widget default Options, the Options argument and using the theme as fallback when colors/fonts/other styles aren't explicitly defined.

All widgets should be written to receive one valid theme name and reference the attribute set of that theme which is loaded from files.

This would be very noisy and would be effectively the same as the application code using dvui.setTheme before and after the widget call. I don't think anything has to change here. If you want, the application can load many Theme structs in memory and query a specific theme to set the override colors on a per widget basis, which sounds like what you want. I don't believe it should be integrated into the dvui widgets though.

As for the loading from file, it's also very possible with the "multiple loaded Theme structs picked from at runtime" solution above, just that the list of themes is dynamic and you load them from files.

If no theme name is given, widgets should rely exclusively on user-provided attributes.

I can see the benefit of some way to stop widgets from reaching out to the theme for colors/fonts. Perhaps a boolean on Options to say if the theme fallback is allowed or not would be enough, with some warning being logged if the application doesn't provide a used value? That would still be some overhead for most applications, but relatively small so it might be worthwhile.

Every widget should assume sane defaults for every attribute left unset by the user or theme.

I believe this is what dvui does now with widget defaults and the Window.theme field to set application wide, and consistent, defaults.

Users should be able to load and unload themes from User Land by providing a file name. Built-in theme aliases can be provided as an afterthought.

I believe this is a application concern and dvui should just supply the tools to serialize/deserialize the themes. It's up to the application to choose storage and runtime structure of multiple themes.

All attributes should be state-dependent.

I think i know what you mean. No global state should affect the attributes, like the windows effectively global theme field. The look of a widget should effectively be a "pure" function. I think this would be too hard to do more that the "log a warning if value isn't provided" I described above. The window theme I think is a good design for most applications to have a coherent visual look without the need to pass duplicated, or at least very similar, Options to each widgets to make them look the same.