Next stage themes

[dbolack-ab]

Overview

The current theme schema imposes some specific assumptions and in turn limitations on the long-term capabilities of Homebrewery. Okay. That might be a little hyperbolic.

Currently, themes are tightly bundled with the code base which creates challenges for the maintenance and integration of third-party themes.

Here is my proposal. Each top-level bullet point is a distinct wave of work.

1. Pull the existing themes from the codebase. ( V3 only )
   1. Organize each (current) theme in its own project
   2. Place all global resources in the Blank Theme. This is fonts, snippets, etc. that are or could be shared between themes.
   3. Reorg the files for each theme to a directory structure with an expected format and naming scheme ( more on this later )
   4. Update the build process to download the latest release into the /themes/v3/ folder using /
   5. Add version storing to brews, automatically setting to the version of the theme at the time of creation
2. Add code for brew version manipulation
   1. Store the original version for rollback
   2. Provide an interface on the brew config for changing theme version ( a pulldown )
   3. Provide notification(s) that a new version of a theme is available.
3. Allow User theme submissions
   1. Create Datastore additions to track user theme URIs and share state
   2. Create a new static path for user themes
   3. Create a User theme install process (assume Github)
   4. Create a User theme deletion process
4. Allow Use of shared themes
   1. Expand the theme selector to include shared user themes. Probably want to switch to something more like the brew selector that shows the user, theme name, license, and tags.
   2. Create a theme use tracking in the data store
   3. Change theme deletion to disable listing if there are still known brews using a theme. This should permit existing brews to continue to work if a user withdraws their theme.
   4. Update brew loading to verify a theme is installed and install it if not before rendering. This will allow any situation where the user theme cache is missing a user theme.
5. Add a way to flag a user as a publisher account and tag their themes as "official"

Theme Format

Expected Files:

settings.json : This is a metadata file for the theme. This extends the current version by adding the license type, a short description, and brew tags. Optional contact information such as the themes repository should also be considered.
theme.less : The theme styles

Optional Files and folders:

snippets/ : folder for snippets loading/linking
fonts/ : organizational folder for fonts
images/ : organizational folder for images
license.md : If the chosen license type requires including a file with the license terms, this is it. Distinct licenses for any shared assets should also be included here.
snippets.js : snippets additions for the theme
catalog.brew : A brew for showing off/demonstrating features of the theme.

Perhaps this, assuming desirable beyond just me, should be considered the basis for V4 themes?

[dbolack-ab]

#3208 has demo work on this topic.

When I started working on the decoupling I noticed that the four V3 themes are all mostly the same. I have cloned the assets into each theme as though they do not. I think that the "final" starting release of each theme will need some heavy redaction and alteration once the "blank" theme is finalized.

I feel that it would be best to make Blank as system/platform agnostic as possible and push the notion of a 5e ( and 6e ) base into their own base themes.

There also needs to be some discussion of snippets.

[dbolack-ab]

Now that I have spent a lot of time working through implementations of part of this setup I have come to the conclusion that the solution above has a LOT of overthinking involved.

1. Enable Using a Brew as a Theme
   a. Tag a brew as meta: theme or meta:Theme
   b. Enable Brew Theme Selector to include theme tagged brews in the selection list
   c. Inherit the Brew's theme and style as the brew's style.
2. Create a "Naturalcrit/Homebrewery" user for hosted themes.
   a. Create a process for user theme submissions
   b. Create a default template for formatting submissions
3. Allow favorited themes marked as themes to appear in the Theme selector.

** Edits: Changed the tagging labels based on recent live discussions.

[dbolack-ab]

Step 1 is implemented in #3321

Part of why 2 is important is that we need to be sure that commonly used themes keep outside ( art, fonts, etc. ) assets available by cloning them to the naturalcrit server.

[5e-Cleric]

This makes sense to me too, can work on the theme template. Or rather, style guide + minimum changes?

[5e-Cleric]

Suggested change to avoid overflow:

Overflow to avoid

Changes and result

Wrap the name of the theme in a p element (or any you want, i guess span or label would be more appropiate), then in the LESS:

.navDropdown .item > p {
    width: 45%;
    white-space: nowrap;
    text-overflow: ellipsis;
    overflow: hidden;
    height: 1.1em;
}

Which results in:

[dbolack-ab]

Added.