Skip to content

Themes v3 Part 1 "2.1" codenamed "One step for themes, a giant burder for code reviewers"

HJ requested to merge themes-accent into develop

TL;DR

* Future-proofing

* Adding missing color slots

* Refactor copypasta spaghetti into something declarative

Changes in general:

  • More color slots
  • Better text contrast calculation and text color generation
  • All color slots are overridable
  • Single point of truth - all color slots must be declared in one place (theme_data.service.js), everything else will be made based on that.
  • Limited backward compatibility with v2
  • Better forward compatibility and future-proofing.

UI Changes

  • Updated color input
    • Updated layout to include color input and text input in same visual box
    • Support for transparent keyword, displays checkerboard
    • Support for computed colors (i.e. --accent), shows resulting color (technically, fallback)
      • FIX shadow control not showing color
    • Better control of "override" checkbox
  • Updated opacity input
    • Better control of "override" checkbox
  • Added bunch of controls to "Advanced" tab, this will be refactored later. UI needs to be changed drastically in a later MR.

New color/opacity slots

  • Accent (mutually optional with Link)
    • Interface links (i.e. not post contents)
  • Button states
    • Disabled
    • Toggled (previously Pressed)
    • Pressed (:active)
  • Tabs
    • Tab color+text color
    • Active tab text color, inherits from bg since active tab is essentially transparent
  • LightBg
    • LightBg now redefinable, completely with its own Faint, FaintLink, Link, Text, Icon colors.
    • SelectedPost - background/text of selected post
    • SelectedMenu - background/text of hovered/selected menu items, this includes navigation, autocompletion and some selectable list in user settings
  • Popover color/opacity slots
  • Dropdown menu hover slots (or make them use SelectedMenu)
  • all TODOs in the code mentioning needing new slots. Removed SOME TODOs, the only remaining colors seem to be affecting the buttons, i.e. "primary button" and "danger button". Given how complex and copy-pasty button colors are, i would rather refactor theme framework to properly support states/variants/layers without the need for copy-paste, however i've exhaused my refactor quota for now.

Engine

  • Initially load only needed theme for anon viewer, don't wait until all themes are loaded.
  • Major overhaul of how slots are computed: copypaste, manual cloning and short-circuiting are gone, now replaced by defining slots, dependencies and how they are defined in declarative way.
    • Color slots are defined in a SLOT_INHERITANCE object, slots can have dependencies and color functions. This allows define color slots declaratively, this clears up which color depends on which and how specific colors are defined. It also eliminates need for cloning colors manually, since system clones colors for you.
    • Text colors are defined with textColor, layer, variant properties. LAYERS object defines what layers there are in UI (i.e. btn lies on top of bg which lies on top of underlay), and this information is used to properly generate text color i.e. getTextColor for semi-transparent areas by alpha-blending layers beneath text.
      NOTE: I'm not entirely pleased with this solution and presence of DEFAULT_OPACITY object, but this will do for now until next steps and I've figured out how to make it more reusable.
    • Dependency resolution is handled by sorting slots topologically (i used some approach from wikipedia)
      • Add additional sorting to ensure that "basic" colors are usable for computed properties. (partially implemented)
    • ALL slots can be redefined by theme now. Just in case.
  • transparent keyword - allows forcefully setting opacity to 0 without affecting user's opacity and allows user to change color to their choosing if needed or avoid it changing.
  • computed color support - same as with colors in shadows - you can use --slot (i.e. --accent) as color for (some) slots, in additional you can supply a number after a comma (i.e. --accent,20) to make color brighter or darker (depending on if theme is light on dark or dark on light
  • added better backward/forward compatibility
    • Theme snapshots - exporting theme can also store ALL slots that theme generated at the moment, so exporting theme from newer FE version and importing into older FE version will allow importing a snapshot instead so theme looks as intended - mainly because inheritance may change in future, getTextColor function, etc. etc. and it could potentially break themes. Right now some themes give slightly different text colors for alerts in panel header for instance.
      • Make it work for possible v2.1 -> v2 downgrades in localstorage
        • It mostly works, but there is a problem with lightBg definition.
      • Test v2.1 on v2
        • lightBg doesn't work well with v2 - it's definable but you can't control text color for it, so it really should be left alone for snapshots and other field used instead highlight for instance
      • Test more themes v2 on v2.1
      • Test v1 on v2.1
      • Add compatibility mode for colors not definable in v2?
      • v2.1 -> v2 -> v2.1 doesn't work properly
    • Added versioned source field, aforementioned theme is now used for snapshot, for v2 compatibility (because of possible missing fields)
      • Add UI for allowing forcefully importing source instead theme (snapshot) if version of source newer that FE's version.
        • Test pseudo-v2.5 themes
Edited by HJ

Merge request reports

Loading