Themes v3
Approach update (long term):
- Changes entire approach to theme/customization:
- 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?)
- Possibly allow
- Switching themes with a picker or from file1 saves theme reference (and a copy of theme data) instead of applying slots directly.
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
- Custom color picker:
- 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
orlink
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 usingv3compat
field (see below)
- Requirement change - either
-
Addso that we keep backward compatibility with v2 (v3compat
key to theme object__pleroma_theme_version
remains at2
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 usev3compat
store differences/inconsistencies.- The example would be aforementioned
accent
- if theme declaresaccent
but notlink
we still have to definelink
in theme file so that it works in older FE, but it makes it defined color, to solve this we'll leave a flag inv3compat
, something likeundefinedColors: ['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 likecolors: { bg: 'gradient1' }
(syntax not finalized) to override v2 data.
- The example would be aforementioned
- 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 tov3compat
? - 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 currenttheme
field will have all colors defined, generated from basicallypreviewColors
- 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.
- What about another updates? Do we make
- 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
Edited by HJ