Brew Themes

Swappable brew themes will allow users to change documents from PHB style to MM, DMG, non-WOTC styles, and eventually custom and shared styles from other users.

Built-in Themes

We already have the capability to live-swap style sheets (we do this to change between Legacy and V3), and we could get away with simply adding more styles to that list and swap them in a similar way. However, as the list of Theme grow, there are more special cases such as unique snippets, fonts, image resources, etc. that we may also need to consider part of the Theme. Hence, I propose that Themes consist of a set of multiple files linked together:

Theme 1 (i.e. DMG)/
 ├─ Settings.json	 : V3 or Legacy, Creator credit, Base Theme
 │                         (i.e. DMG is built on PHB, so default to Base Theme behavior where not defined)
 ├─ Styles.less		 : Relevant CSS
 ├─ Snippets.json        : List of snippets specific to this Theme. May overwrite snippets of Base Style
 └─ Widgets.json         : List of editor widgets, as proposed in #1870 
                           (i.e., "if this line has '{{monster', show checkbox to add/remove 'frame' class")
Theme 2/

Theme 3/

Fonts/
 ├─ Font1.woff2
 └─ Font2.woff2

Assets/
 ├─ Inkstain1.woff2
 └─ Inkstain2.woff2

The widgets.json might have a structure similar to the following. Clicking on a line that matches the prefix would signal to CodeMirror to pop up some widget (a color picker, checkboxes, number entry boxes, etc.):

{
  name         : 'monster',
  prefix       : '{{monster',
  widgets :  [
    {
      name : 'frame',
      type : checkBox,
      text : 'frame'
    },
    {
      name : backgroundColor,
      type : colorPicker,
      text : background-color:
    },
    {
      name : positionX,
      type : slider,
      text : left:
    }
  ]
}

However, getting Widgets doesn’t necessarily need to come in the first release of this. That’s a bonus feature that will be filled out afterward via #1870. It’s just important to see how it will fit into the file structure.

Themes would be selected via a dropdown menu in the Metadata tab of the Active Brew that the user is currently editing, preferably with some sort of image preview while hovering over options, including perhaps a “blank” theme with no CSS applied at all except for page sizes and basic column behavior for those who want to fully build a theme from scratch in their Style tab. Any styles a user has in their “style” tab will be applied over the top of the selected theme as normal.

Custom Themes

The next step would be to include an additional item in the dropdown menu of “Custom”. This would reveal a textbox where the user can paste in the share link to another brew (referred to as the “Theme Brew” below), which will then use that brew’s Style tab as the base Theme. Styling would be layered with priority as follows:

1. Base Theme (if any) defined in the settings.json of the theme selected in the Theme Brew (e.g., PHB)
2. Any changes applied over the Base Theme in styles.less of the Selected Theme (e.g., DMG)
3. Additional styles specified in the Theme Brew’s style tab.
4. Additional styles defined in the Active Brew’s style tab.

Minimal Viable Product

I think as a first release, the minimal viable product can simply be:

• Have two more themes
  • One built from the existing PHB (DMG? created by /u/AeronDrake on reddit) (See #1339) (c
  • One totally new (@Gazook89 's “journal” style?) (See Reddit)
• Themes are organized into folders with
  • style.less
  • settings.json with at minimum the renderer and Base Theme defined.
  • snippets.js so each theme can have its own snippets (unless they are identical to the Base Theme, then not needed)
• Interface to select theme
  • Dropdown menu in the brew Metadata panel
  • Greyed out when Renderer is Legacy.
  • Themes selection is saved into the brew metadata
  • Preview images when hovering over a theme

Thoughts?

[calculuschild]

Alright, so snippets.json probably needs to be snippets.js so it can contain generator functions for more complicated snippets similar to the current snippets files. …although that does complicate things for users defining their own snippets eventually as part of a Theme Brew; I’m not keen on allowing user-made themes to have access to executable javascript.

Perhaps… our built-in themes use a .js file for our convenience, but (eventual) user-generated Theme Brews still are limited to JSON, or even some kind of entry form that is stored as JSON?

[G-Ambatte]

This might be more appropriate as a general snippet, or included as a theme-specific snippet, but the recently released Dragon of Icespire Peak free preview has double-sided half page NPC cards on pages 11 through 16, which I personally think look great. I’m not sure if similar NPC cards have appeared in any other supplements or resources.

I have included images of one here to demonstrate exactly what I’m talking about:

Front:

Back:

This does seem like something that could be replicated in Homebrewery without too much difficulty.