Improve flat theme, colours

[dhardy]

These theme adjustments are inspired by @hummingly. Current progress:

• make FlatTheme the default (this might be renamed later; the ShadedTheme will likely stay unchanged for now other than colours and minor tweaks)
• adjust button border and fill
• adjust radio- & check-box border and fill
• use borders for navigation highlight
• revise colour categories (WIP: choose between text and text_invert automatically since the text background colour isn't currently available; this should be doable but I may not bother)
• revamp colour schemes

Shadows are an important detail according to @hummingly. Current ideas are to use a post-processing shader for pretty soft shadows from height or to draw using lines (but then curved corners are tricky).

Other widgets such as EditBox and ScrollBar are currently untouched.

[dhardy]

On second thoughts, we may not need shadows. I'm also not sure what they should look like with a dark theme.

Using the widget border to indicate focus seems fine for checkboxes, but may not the best for buttons. Another possibility would be to use the accent_soft colour (see changes to colors.rs for doc) for the button background, overriding the button colour if any (it may look a bit weird on the day/night icon buttons, though they are just low-quality stand-ins anyway).

Edit: yes, potentially this looks better (though not with the current "dark" colour scheme, and the text colour needs fixing):

[hummingly]

On dark themes the shadows become usually inverted, making it look like light is shining behind an object.

Shadows are to make controls feel like actual objects that can be touched and moved. However, I don't think it's necessary for the flat theme. I designed the mockups with the shaded theme in mind. The disabled states are actually just a flat theme.

As for colours you might try to compute it using a color model like hsl and a perceptually uniform color space like CIELAB (hsluv is an example, rust-hsluv is Rust implememtation). For example for hover the accent colour becomes lighter by adding 20 to the lightness.

I haven't tried it out myself yet, so it has to be seen how to use it at scale effectively.

Gold mine of design information: https://programmingdesignsystems.com/
Discussion regarding common colour spaces: https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
Youtube video using brightness and co for theming: https://youtu.be/oHcTn83M1ls

[dhardy]

Regarding colours, I use palette to map from sRGB to linear for all transformations. I already have slightly-crude logic to produce highlight/depress/disabled variants of colours. Maybe this could be better but it seems okay.

These accent / accent_soft / nav_focus colours I think perhaps it's better to leave configurable, since it can be acceptable to have accent the same as accent_soft or nav_focus but not both, since there should be a good contrast between the latter. If you run this code it's easy enough to play with these colours by editing the theme config file (see the README on setting up a config file).

[dhardy]

[dhardy]

Care to comment on #238?

[dhardy]

Colours

When the text box doesn't have focus the underline is dark grey in @hummingly's concept art. This appears to be a unique colour? I'm attempting to reduce the number of unique colours down to something reasonable, but this doesn't fit elsewhere (except possibly as the scrollbar handle, though it's probably darker).

Besides that, I have the following list of colours (with (programmable) generating logic for hover/pressed/disabled variants):

• background
• widget border (generated variants)
• widget fill (generated variants)
• accent (generated variants)
• accent fill (generated variants)
• navigation highlight (only for some themes)
• track fill (generated variants): scrollbar / slider background
• track handle (generated variants): scrollbar handle
• widget fill (active): i.e. scrollbar
• text label
• text (disabled)
• text over widget fill
• text over accent fill

[hummingly]

I added this dark gray because in unfocused state the background is grayish and it might be confused with the disabled state. I also didn't want to have it so colourful but most of all you can probably not the see at a first glance that the bottom border is thicker on focus.

However, it might be better to just make it by default use a lighter accent color and drop the hover state. I think it is enough to change the cursor to the text beam icon on hover.

[dhardy]

No, I think using the accent colour to indicate input focus is a good idea. Using the soft-accent colour otherwise isn't a clear enough distinction. Not showing this thicker bar at all (only the regular border) without focus is another option. With my current colours the background gets brighter on highlight and input focus, so using it for hover highlight isn't really necessary.

[CryZe]

Is there a reason the text box uses a serif font? Doesn't really fit the theme imo.

[dhardy]

I think that's all for this PR. It's not complete of course:

• frames, separators might want better graphics
• menu entries definitely do want better graphics (how? okay: more space especially before sub-menus, proper shadows)
• shadows
• some colour reform (mentioned above)
• the combo-box should have a down-arrow
• text buttons should have larger left/right margins? Or even expand to fill available space?

@CryZe serif fonts are (currently) the default for edit fields (I prefer function over form). This is set by the theme configuration which is user-editable but (ironically enough) not by the individual theme currently.