We should revamp our styles

[tomlm]

If you look at these two styles from avalonia:

Simple Theme:

Fluent Theme:

I think we should add some more named colors to our scheme:

• ActionEnabledBackground/ActionEnabledForeground
• ActionDisabledBackground/ActionDisabledForeground
• InputEnabledBackground/InputEnabledForeground
• InputDisabledBackground/InputDisabledForeground

Perhaps Checked variations as well?

[jinek]

Initially i just tried to keep as few colours as possible. I feel lack of strategy in the design overall.
May be, for instance, we should align to turbo vision approach rather than avalonia.
Lets say, we introduced colors you mentioned, what would be the values for 4bit themes there?

Out of topic: i was thinking it's such a pain to keep templates/styles updated with each upgrade. Could we teach LLM to convert Avalonia styles to Consolonia ones, using some guideline? In this case we would work on the guideline, colors etc rather than matching what was changed and needs to be synced from avalonia.

[tomlm]

What is involved with the template definitions? Is it mostly font size layout changes, or colors or?

[tomlm]

It would be sweet if we could have 1 theme which is aligned with something like this:
https://www.logicui.com/colorgenerator

[jinek]

What is involved with the template definitions? Is it mostly font size layout changes, or colors or?

Everything plus additional things which do not exist in avalonia at all, like buttons - on consolonia has shadow, has delayed press. I dont think it can be automated, thats why thinking about LLM

[tomlm]

I was doing a little survey and I think we might be able to get away with this as themes:

// basic text fore and background colors
ThemeForegroundBrush  
ThemeBackgroundBrush

// alternate ? not 100% certain on this one.
ThemeAlternateForegroundBrush  
ThemeAlternateBackgroundBrush

// Buttons checkboxes, radio buttons etc.
ThemeActionForegroundBrush
ThemeActionBackgroundBrush
ThemeActionCheckedForegroundBrush
ThemeActionCheckedBackgroundBrush
ThemeActionDisabledForegroundBrush
ThemeActionDisabledBackgroundBrush

// input controls
ThemeInputForegroundBrush
ThemeInputBackgroundBrush
ThemeInputDisabledForegroundBrush
ThemeInputDisabledBackgroundBrush
ThemeInputPlaceholderForegroundBrush
ThemeInputPlaceholderBackgroundBrush

// Listboxes and data grids and such
ThemeItemsForegroundBrush
ThemeItemsBackgroundBrush
ThemeItemsSelectedForegroundBrush <-- Is this always just invert of Itemsforeground/background ?
ThemeItemsSelectedBackgroundBrush

// menus
ThemeMenuForegroundBrush
ThemeMenuBackgroundBrush
ThemeMenuDisabledForegroundBrush
ThemeMenuDisabledBackgroundBrush

// Hotkey colors (accelerator keys)
ThemeHotkeyForegroundBrush
ThemeHotkeyBackgroundBrush

// Scroll bar
ThemeScrollbarForegroundBrush
ThemeScrollbarBackgroundBrush

// general things
ThemeBorderBrush
ThemeShadeBrush

// I noticed fluent talked about semantic theme colors. This seems like a useful idea.
ThemeSucceessForegroundBrush
ThemeSucceessBackgroundBrush
ThemeWarningForegroundBrush
ThemeWarningBackgroundBrush
ThemeErrorForegroundBrush
ThemeErrorBackgroundBrush

// We should make all of the symbols in our controls themable.
ThemeRightSymbol Examples:🞂 ➩ → ↣ etc.
ThemeLeftSymbol Examples: ◀ ⧏ 🢤 etc.
ThemeUpSymbol Examples: ▲ etc.
ThemeDownSymbol Examples: ▼ ▽ etc.
ThemeCloseSymbol Examples: x X ╳❎❌ ⨯ etc.
ThemeCheckedSymbol Examples:  ⌧ 🗹 🗷 ⮽ 🗵 ☑
ThemeUncheckedSymbol Example: ☐
ThemeIndeterminateSymbol Example: ▣
ThemeSelectedSymbol: Examples:  ◉ ⏺
ThemeUnselectedSymbol Examples:  ⭘ ◯ ⚪ 🔘
ThemeExpandedSymbol Examples: ▼
ThemeCollapsedSymbol Examples: ▶ 🞂
ThemeRefreshSymbole: Examples: ↺ ↻ 🔄

This doesn't seem too far off what the themes already are.

Given this as the structure for our control theming then I thnk we can do Turbo, Material style, Fluent style, monochrome etc.

Then of course there is bigger theme things like Buttons have drop shadows or not, menus

[jinek]

Alternative is needed for popups and alternative datagtid rows.

[tomlm]

Symbol can be multiple chars I think so TurboVision might use
ThemeUncheckedSymbol = "[ ]"
ThemeCheckedSymbol = "[x]"

while material would use richer Unicode chars.

[tomlm]

Here's a fluent design generator
https://fabricweb.z5.web.core.windows.net/pr-deploy-site/refs/heads/7.0/theming-designer/index.html

It's cool, but much much more involved to map to the controls.

I kind of like the material design, it seems simpler.

[tomlm]

regarding 4 bit and 3 bit I think we just have a templates which map to the 16 color or 8 color.

ThemeForegroundBrush   = White
ThemeBackgroundBrush = Black
ThemeDisabledForegroundBrush = Gray
ThemeDisabledBackgroundBrush = Transparent

etc.

If a color comes through that is not a 4 bit color, then we map the color to best guess 4 bit color, but the theme would be expressed only via 4 bit or 3 bit colors.

I think that also works for monochrome.

ThemeForeground=White
ThemeBackground = black
ThemeDisabledForeground = White
ThemeDisabledBackground = Black

etc.

Basically the RenderTarget would only emit the correct codes for the current rendermode, but the Theme would map correct values down to RenderTarget.

Bitmap renderer would map to correct color maps. Everything else would be theme based.

[tomlm]

We might consider having a 2 stage theme for material designs.
Our templates would be expressed in terms of ThemeForegroundBrush/ThemeBackgroundBrush, etc.
We would map the material design values to the themes

ThemeForegroundBrush = Primary
ThemeBackgroundBrush = OnPrimary
ThemeAlternativeForegroundBrush = Secondary
ThemeAlternativeBackgroundBrush = OnSecondary

etc.

The alternative would be to adopt the material design names for our templates

    <color name="primary">#6750A4</color>
    <color name="onPrimary">#FFFFFF</color>
    <color name="primaryContainer">#CBC0E6</color>
    <color name="onPrimaryContainer">#201933</color>
    <color name="secondary">#625B71</color>
    <color name="onSecondary">#FFFFFF</color>
    <color name="secondaryContainer">#DCD8E6</color>
    <color name="onSecondaryContainer">#2C2933</color>
    <color name="tertiary">#7D5260</color>
    <color name="onTertiary">#FFFFFF</color>
    <color name="tertiaryContainer">#E6CDD5</color>
    <color name="onTertiaryContainer">#332227</color>
    <color name="error">#B3261E</color>
    <color name="onError">#FFFFFF</color>
    <color name="errorContainer">#E6ACA9</color>
    <color name="onErrorContainer">#330B09</color>
    <color name="background">#fcfcfc</color>
    <color name="onBackground">#323233</color>
    <color name="surface">#fcfcfc</color>
    <color name="onSurface">#323233</color>
    <color name="surfaceVariant">#e0dee6</color>
    <color name="onSurfaceVariant">#5e5c66</color>
    <color name="outline">#8e8999</color>

[tomlm]

I do really like how LogicUI has primary, secondary and tertiary containers.
Playing around with TurboVision app, they use colors on buttons to represent

• Control has Focus
• Control is default (for Enter key)

[tomlm]

regarding the templates, how do you do it today? Do you look at each template in Avalonia.Themes.Simple or something and hand tweak it?

Given we have a source (like button.axaml in Avalonia.Themes.Simple) and an existing target (consolonia/button.axaml) I definitely could write a tool to do that conversion.

[tomlm]

Whew. OK that was a train wreck. I tried using OpenAI to generate the output and it just couldn't help itself by

• Creating malformed xaml
• Applying arbitrary layout
• Making up theme template names
• etc.
  I don't think that's going to end up saving any time.

[tomlm]

I'm starting to think we should have 2 or 3 core themes

• TurboVision - literally using the turbovision design style [ ] for checkbox, drop shadow for button, etc. This would be designed with 4 bit/16 core color and work well for non high color terminals. This would have variants
  • Light/Dark/HighContrast (Monochrome?) variants of color scheme but not change the control templates.
• Simple - This leans into high color and rich templated unicode support for symbols (like 🗹 I've been exploring above) and be built around a core color theme generator like LogicUI. Variants would be simple using the light/dark variant pattern LogicUI has created. That would look fantastic, give people a sweet simple way of creating their own theme.

Put another way, let's not hack up turbovision to achieve the rich environment support unless we think that's a more efficient way of doing it.

[jinek]

Are you saying we should create separate templates for turbovision vs fluent? I think maintaining two sets of templates will be 2x harder.
Speaking about how to define colors, I think makes sense to adopt already existing definitions like from some generator

[jinek]

Why this should be different?

ThemeInputDisabledForegroundBrush
ThemeInputDisabledBackgroundBrush

vs

ThemeMenuDisabledForegroundBrush
ThemeMenuDisabledBackgroundBrush

[tomlm]

I dunno 🤔 lol

[tomlm]

Do you like idea of templating the symbols?

[jinek]

Yes. I'm up for anything which could allow to have universal template which could be further colored into different themes.

[tomlm]

I experimented to see what a "Simple" theme might look like in chars:

I think it looks pretty tight. The only thing that is different from Turbo is

• symbol substitution
• I'm drawing the outline of the input controls and buttons using border chars instead of color highlights
• I'm implementing ToggleButton and ToggleSwitch

[tomlm]

Something I'm noticing is that it seems like we could support actual border with border thickness of 1, 2, and maybe 3 using the line art chars for 1/8, 1/4, /1/2.

So drawing a rectangle would use box chars, but border brushes could use tight vertical and horizontaol chars. That's what I did effectively to put the box around the combobox. With the caveat that it takes up a whole char size around (Which is why I left the top annotation off).

[jinek]

I think we should draw similar set of sketches for

1. TurboVision
2. Monochrome
3. May be htop/btop/bpytop theme
   With this we can compare the difference and extract it to control properties and further to theme resources or to theme resources directly if something is not defined in the control (like shaddow character or scroll characters).

But still, manually converting Avaloina templates is a pain. And furthermore, lets say, even if chatGPT model learned how to convert that, any next time it might convert differently due to the fact we do not own the model data.