Switching themes with a picker or from file1 saves theme reference (and a copy of theme data) instead of applying slots directly. This should improve "load Breezy theme with different color scheme" scenarios and make "keep" checkboxes mess obsolete
Separate concepts of Color Scheme/Customization and Theme
Color Scheme and Customization is a Patch to existing theme. Most basic example is redefining 8 basic colors when using Breezy (a Color Scheme) or making background a bit transparent (a Customization)
Theme is a full-feature theme, i.e. Breezy, default fallback theme, Redmond
Themes and Customizations are stored separately, so that you can keep your color scheme and customization easier when switching themes.
Extended API for themes - allow themes to define their own color slots via variables, for instance to allow you set up colors for gradient in title bar without piggybacking on some existing color slot.
Possibly allow calc to allow themes override existing derivation (i.e. allow redmond to define shadows differently depending on background color?)
UI updates:
Add "expert options" checkmark:
Hides "Advanced" and "Shadows" tabs from tabbar
Hides optional options (heh) in "Common" tab (i.e. opacity, foreground text/links, "see more" text), "clear" buttons.
Unchecking button should move user to "Common" tab if they are on a tab that's about to become hidden.
Also should hide "keep" options and help text.
Update ColorInput control to have:
Custom color picker:
For platforms that have atrocious color pickers (I'm looking at you, Android)
Allow LCh/Lab color space picker?
Gradient editor
Variable selector
Keyword selector (i.e. transparent)
Proper preview for all above cases
Fix bugs related to shadow editor [partially done]
Engine updates
Add following shadows:
Input focus
Input hover
Disabled button
Tab
Link
Add ability to define shadows into custom slots that can be referenced from standard slot, i.e. being able to define "common-button" shadow and use it in button, button-hover etc.
Add "name" field for elementary2 shadow definition for easier navigation and ability to navigate between shadows more easily.
Allow to define v2-only shadows for by marking them as such. (this is a requirement for gradients support)
Add gradient support for certain color slots.
Gradients are stored in separate object like shadows but can be edit in-place
Some color slots can reference a gradient by name instead of a solid color. Mostly intended for backgrounds but in theory could be used to make gradient links.
Add "gradientless" preview support to check backwards compatibility
Completed stuff
Add accent color slot:
Requirement change - either accent or link has to be defined, or both. If one of them is not defined other one is used. This requirement change would break compatibility but we can keep it by using v3compat field (see below)
Add v3compat key to theme object so that we keep backward compatibility with v2 (__pleroma_theme_version remains at 2 for compatibility sake since older FE will freak out if it's !== 2) - everything that's not entirely compatible shall go in there. The idea is to generate a v2-compliant theme that can be used with older FE and use v3compat store differences/inconsistencies.
The example would be aforementioned accent - if theme declares accent but not link we still have to define link in theme file so that it works in older FE, but it makes it defined color, to solve this we'll leave a flag in v3compat, something like undefinedColors: ['link'] so that v3-capable FE can ignore definition.
Another example would be gradients - you can't use gradients for color slots in v2 so v2 will get a solid color fallback and v3compat will have something like colors: { bg: 'gradient1' } (syntax not finalized) to override v2 data.
Most of the stuff above still applies, however there are problems with specific approach:
What about another updates? Do we make v4compat even if it's a minor update? Do we add another version number to v3compat?
The "Diff" approach imposes a tremendous amounts of logic to keep the compatibility - if we have [[incompatible]] then [[do thing to make it compatible]] and also [[check if we need to undo the [[thing to make it compatible]]]].
Different approach would be to have a separate source field that has a theme object in most recent format, complete with an actual version number, meanwhile current theme field will have all colors defined, generated from basically previewColors - so a theme is essentially a snapshot of what theme's supposed to look like and what it looked like at FE version it was made in. Version number of source won't make theme incompatible but it would allow older FEs import the snapshot and display a warning that it was made in newer version and might not look the same.
Add following colors:
Selected menu (fallback lightbg) (used in Timeline/DMs/Mentions switcher(s))
Selected post (fallback lightbg) (currently selected post)
Active button (fallback btn) (also: pressed)
Active button text (fallback btn text) (also: pressed)
Disabled button
Disabled button text
Tab definitions
Popover background/opacity
Shadow background/opacity (inherits popover) ed note: dafuq did i mean by 'shadow'???
Underlay background/opacity (that transparent black background between panels and wallpaper)
Add support for transparent keyword to avoid collisions with user opacity customizations
Bugfixes
Fix lightbg generating lighter background instead of darker one on light themes.
Footnotes
Files will declare themselves as either color schemes/patch or full theme↩
Elementary shadow refers to one bit of shadow, i.e. 0 0 0 0 black while complete shadow means whole chain of elementary shadows ↩