[imgui] additional theme options

[postspectacular]

The current theme system of @thi.ng/imgui is quite limiting. I'd like to hear from people which additional options might be useful - a wishlist of sorts.

When proposing additions, please also think how realistic it is that these might be easily achievable in WebGL (e.g. gradients, thick borders, rounded rects etc.). For some of these it might be best to provide some pre-rendering functionality and a new set of components working exclusively with texture atlases (or SDF-based shapes/shaders), instead of generating complex webgl geometry, requiring expensive tessellation...

[postspectacular]

Some initial list:

• outlines - currently only used for displaying keyboard focus, but outlines would also be useful more generally
• component specific config - e.g. the hover colors for buttons can conflict with those of sliders (if the slider label is partially on top of both active slider area and background). currently there's only a single set of hover colors. We could look into using the theme stack to achieve per-component-type overrides... I'm concerned about adding component specific config to GUITheme, since not extensible for custom component types.
• proportional fonts - @thi.ng/webgl-msdf already supports those, but not compatible w/ Canvas2D. Need some form of font abstraction...

[nkint]

Hi! I still haven't played with imgui package a lot so I'm not completely aware of all the options

component specific config

I'm totally ok on avoid adding component specific config to GUITheme.

My idea is to use a set of color variations. I'm thinking of accent-# or primary- or secondary- color names (for example in material.io palettes ). Does it make sense?

[postspectacular]

@nkint instead of adding these variations to the theme directly, a simpler way would be defining them as derived themes and then just pushing/popping them on/off the theme stack:

const MY_THEME = { bg: "red", fg: "white", ... };
const MY_THEME_PRIMARY = { bg: "yellow", fg: "black", ... };
const MY_THEME_SECONDARY = { bg: "cyan", fg: "blue", ... };

Since beginTheme() & withTheme() only require partial themes and merge those with the existing top-most theme on the stack, these primary/secondary variations can be very minimal.

This approach would also not tie everything to this fixed setup of accent/primary/secondary...