Theming and style language

[willmcgugan]

We need a system to allow customization of styles, and enforce a consistent look and feel.

• API to switch between color themes
• Semantic styles to enforce a consistent look and feel with widgets

Something inspired by Posting...

[darrenburns]

Some ideas and a bunch of questions that would be good to chat about:

• Add App.theme_name (str) reactive which is set to the theme name.
• Add App.theme read-only property which gets the "theme object"?
• Add App.register_theme(theme: Theme) which allows "registering" a theme. A registered theme will appear in the command palette and is just stored in a dict at the app level.
  • The equivalent for unregistering a theme.
• Define a Theme object or expose ColorSystem (possibly rename to Theme?).
  • The ColorSystem object is really convenient because it "fills in the blanks" nicely when values are missing. In Posting, you can define a theme with just a couple of colours and it still looks reasonable thanks to the ColorSystem. Users could provide values for primary, secondary, etc...
• (Possibly) add a App.theme_changed reactive of type Signal[Theme]. Rich renderables don't easily have access to colours from the theme, and when the theme changes they need to be able to refresh themselves to grab the new values from the theme. (Perhaps this should be handled entirely by component classes though?)

Q - How should this interact with App.dark?

Posting has no concept of "dark mode" vs "light mode". It just has themes. Should App.dark become something like App.theme = "textual-dark"? The problem was that colours pretty much always needed tweaked when put against a light background vs a dark background.

I'm also worried that enforcing "if you design a theme then you need to make sure it has a light variant" isn't ideal.