User customizable note colors

[bfollington]

Fixes #1061

• Store color as header
• Allow updating color from metasheet
• Read headers from DB
• Refresh all views when color changes
• Add color to WellKnownHeaders

This change dials back the use of color in the editor/viewer in anticipation of the next chunk of work: designing the mini-editor & full editor using card styles.

Screen.Recording.2024-01-09.at.12.27.13.pm.mov

[gordonbrander]

A few notes and ideas

[gordonbrander]

I think I would recommend just passing Color at the level of actions. NoteColor can act as a constant we use when assigning colors.

Rationale: the plumbing then supports any color. We enforce defaults at the io boundary. This would allow users to hack the color headers, for example.

If the intent is to support dynamically adaptive colors for light/dark, I believe SwiftUI supports this through the asset bundle (specify light/dark variants of color constants).

Alternatively, if we wanted to keep this in code, we might create a more general type like AdaptiveColor:

struct AdaptiveColor: Hashable {
    var light: Color
    var dark: Color

    func color(for scheme: ColorScheme) -> Color {
        switch scheme {
        case .light:
            return light
        case .dark:
            return dark
        }
    } 
}

[bfollington]

I moved the colors into the asset bundle, see response here #1064 (comment)

[gordonbrander]

I think I would recommend just passing Color at the level of actions. NoteColor can act as a constant we use when assigning colors.

[gordonbrander]

Recommend passing Color in actions

[gordonbrander]

Recommend storing Color

[gordonbrander]

IMO the header name should be Theme-Color and the case name themeColor

Prior art: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name/theme-color

[gordonbrander]

I don't think the header should store constant names. Instead, we should consider storing hex values.

Should we include support for color variants?

Theme-Color: #abc123
Theme-Color-Dark: #abc123

[bfollington]

Updated the header name, see #1064 (comment) RE: storing hex.

[bfollington]

RE: #1064 (comment)

@gordonbrander I think it's a bit more complicated than this. For each of the five note variants we have four colours:

• Light BG
• Light Highlight
• Dark BG
• Dark Highlight

I can see several issues with storing literal color values:

1. schema lock-in: storing 4 values seems hefty but also locks us in to how color presents itself going forward
2. color drift, if we change the defaults slightly the old colors will persist in the remaining notes
3. injecting malicious colors into another user's deck
4. color space, on web vs iOS we are in different color spaces and may want to tailor colors based on that
5. accessibility, it makes high contrast and color-blind friendly modes difficult to implement/make guarantees around

I personally think of NoteColor here more like a simple bucket A, B, C, D or E that I can sort a note into, and perhaps we should use actually generic letter labels instead of colors as the cases of NoteColor? The concern of how that bucket is translated to onscreen pixels feels like a view-level responsibility to me. This would allow us to "theme" the whole app and re-define the colors for A...E at will, users could even customize the colors for themselves.

If we want to support user-defined custom colors per-note right now I think we should consider a NoteColor.custom(String) case that the client can choose to support to varying degrees.

---

I moved all the card colours into the asset bundle, renamed NoteColor to ThemeColor and changed the labels to generic letters as-per the above.

[bfollington]

There is a new syntax Color(.cardThemeColorA) on XCode 15+ but we need these string names for XCode 14.

[gordonbrander]

RE: #1064 (comment)

@gordonbrander I think it's a bit more complicated than this. For each of the five note variants we have four colours:

• Light BG
• Light Highlight
• Dark BG
• Dark Highlight

I can see several issues with storing literal color values:

1. schema lock-in: storing 4 values seems hefty but also locks us in to how color presents itself going forward
2. color drift, if we change the defaults slightly the old colors will persist in the remaining notes
3. injecting malicious colors into another user's deck
4. color space, on web vs iOS we are in different color spaces and may want to tailor colors based on that
5. accessibility, it makes high contrast and color-blind friendly modes difficult to implement/make guarantees around

I personally think of NoteColor here more like a simple bucket A, B, C, D or E that I can sort a note into, and perhaps we should use actually generic letter labels instead of colors as the cases of NoteColor? The concern of how that bucket is translated to onscreen pixels feels like a view-level responsibility to me. This would allow us to "theme" the whole app and re-define the colors for A...E at will, users could even customize the colors for themselves.

If we want to support user-defined custom colors per-note right now I think we should consider a NoteColor.custom(String) case that the client can choose to support to varying degrees.

I moved all the card colours into the asset bundle, renamed NoteColor to ThemeColor and changed the labels to generic letters as-per the above.

Ok, this makes sense for now, although I suspect we may want to consider how to handle custom color values over the long term.

Since these themes are an app-specific concern, I have one more request: let's change the header key to Subconscious-Theme. The value can be a unique key that corresponds to the theme (a, b, c, ...).

We may want to use numbers rather than letters for the theme keys to avoid uppercase/lowercase ambiguity.

Otherwise LGTM

[gordonbrander]

LGTM 🥳