dynamic themes #67

Open
opened 1 year ago by gdamore · 3 comments
gdamore commented 1 year ago

I'm interesting being able to have users change the color themes for various reasons.

What I'm thinking of is some kind of dynamic theme scheme, where applications can extend the theme by setting the "class" of a primitive, and having styling properties looked up via the class.

This would work sort of like how HTML does CSS.

I'm imagining a "SetClass(string)" method on Box, as well as two global functions to set the global theme (SetTheme) and get it (GetTheme) -- these just are locked accessors for a global Theme object (see below).

Then when looking up a color or style setting if nothing is overridden elsewhere, it could look up the details using methods on the Theme object. (Basically Draw methods would do the bit to look up the theme using GetTheme, then look up the attributes they care about on that.)

The Theme object could support loading and unloading via either JSON, or perhaps even just implement CSS (!) - there are plenty of CSS parsers available for golang. I'm not entirely sure I'd want to implement the entire syntax of CSS though -- JSON or even TOML might be the more logical format.

As far as looking up properties, I imagine Theme is like this:

type Theme interface {
GetBool(property string) bool // e.g. for turning on visibility, or borders, opacity
GetStyle(property string) tcell.Style
// Could have GetInt and GetString too, if use cases arise
SetBool(string, bool)
SetStyle(string, tcell.Style)
SetForeground(string, tcell.Color) // convenience - built on GetStyle/SetStyle
SetBackground(string, tcell.Color)
SetAttributes(string, tcell.AttrMask)
encoding.TextMarshaler
encoding.TextUnmarshaler
}

I can try to knock this out and submit a PR if its something you think would be interesting/useful. I could definitely use it in an app (proprietary) that I've developed.

I'm interesting being able to have users change the color themes for various reasons. What I'm thinking of is some kind of dynamic theme scheme, where applications can extend the theme by setting the "class" of a primitive, and having styling properties looked up via the class. This would work sort of like how HTML does CSS. I'm imagining a "SetClass(string)" method on Box, as well as two global functions to set the global theme (SetTheme) and get it (GetTheme) -- these just are locked accessors for a global Theme object (see below). Then when looking up a color or style setting if nothing is overridden elsewhere, it could look up the details using methods on the Theme object. (Basically Draw methods would do the bit to look up the theme using GetTheme, then look up the attributes they care about on that.) The Theme object could support loading and unloading via either JSON, or perhaps even just implement CSS (!) - there are plenty of CSS parsers available for golang. I'm not entirely sure I'd want to implement the entire syntax of CSS though -- JSON or even TOML might be the more logical format. As far as looking up properties, I imagine Theme is like this: type Theme interface { GetBool(property string) bool // e.g. for turning on visibility, or borders, opacity GetStyle(property string) tcell.Style // Could have GetInt and GetString too, if use cases arise SetBool(string, bool) SetStyle(string, tcell.Style) SetForeground(string, tcell.Color) // convenience - built on GetStyle/SetStyle SetBackground(string, tcell.Color) SetAttributes(string, tcell.AttrMask) encoding.TextMarshaler encoding.TextUnmarshaler } I can try to knock this out and submit a PR if its something you think would be interesting/useful. I could definitely use it in an app (proprietary) that I've developed.
Owner

Hey @gdamore. Thanks for your suggestion, I think it would make a great addition. Using a subset of CSS for this is an interesting idea. It seems like it could work, and should be fairly intuitive for end users to write and edit versus JSON. I think it's worth exploring, and if it just doesn't seem like it's worth the trouble/complexity, JSON seems like the next best option.

Hey @gdamore. Thanks for your suggestion, I think it would make a great addition. Using a subset of CSS for this is an interesting idea. It seems like it could work, and should be fairly intuitive for end users to write and edit versus JSON. I think it's worth exploring, and if it just doesn't seem like it's worth the trouble/complexity, JSON seems like the next best option.
Poster

I'm leaning to a bespoke language based on CSS. Regular CSS is just way to complex and tied to HTML.

  1. We will have element types (e.g. "inputfield" or "checkbox" or whatever.)

  2. We will have only a class (no id for now).

  3. Properties can be set using the element type, or the class, or both together, or using a default with the wildcard where neither is provided. For example, in decreasing order of preference:

     list.garrett { background-color: green; }
     .garrett { background-color: yellow; }
     list { background-color: red; }
     * { background-color: #0000ff; }
    
  4. Multiple propeties can be supplied like CSS (and can contain newlines or not just like CSS):

     list.garrett { background-color: yellow; foreground-color: black; }
    

I probably won't use a one of the existing CSS libraries -- I think they are just too tightly bound up with CSS.

I think the above syntax is close enough to CSS that folks will be able to adopt it pretty easily.

I'm leaning to a bespoke language based on CSS. Regular CSS is just way to complex and tied to HTML. 1. We will have element types (e.g. "inputfield" or "checkbox" or whatever.) 2. We will have only a class (no id for now). 3. Properties can be set using the element type, or the class, or both together, or using a default with the wildcard where neither is provided. For example, in decreasing order of preference: list.garrett { background-color: green; } .garrett { background-color: yellow; } list { background-color: red; } * { background-color: #0000ff; } 4. Multiple propeties can be supplied like CSS (and can contain newlines or not just like CSS): list.garrett { background-color: yellow; foreground-color: black; } I probably won't use a one of the existing CSS libraries -- I think they are just too tightly bound up with CSS. I think the above syntax is close enough to CSS that folks will be able to adopt it pretty easily.
Poster

I guess I can't use "Theme" though, since that's already a type in use. I'll use StyleSheet.

I guess I can't use "Theme" though, since that's already a type in use. I'll use StyleSheet.
tslocum added the
enhancement
label 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.