Styles
Tuesday, July 2, 2024
A style will be a collection of user-made changes that override theme and definition data.
Consider: Should one style be capable of overriding data from more than one set of definitions?
The goal is to be able to support this. The following is an example of JSON data for a style intended to fill the borders of all windows/dialogs for the Nebula application:
{
"_aliases": {
"rainbow_gradient": "Gradients/Rainbow (huntermalm).json"
},
"Color Dialog": {
"attributes": {
"Border.Fill": "L:rainbow_gradient"
}
},
"Gradient Dialog": {
"attributes": {
"Border.Fill": "L:rainbow_gradient"
}
},
"Main Window": {
"attributes": {
"Border.Fill": "L:rainbow_gradient"
}
}
}
The biggest thing to consider is the difference between separation and grouping of the above widgets/attributes when compared to their definitions. The widgets being stylized are defined by Fusion and Vortex, all in separate definition files, yet the above intends to override their borders and group this data into a single file (although this may not be a requirement; it is just cleaner that way. More complicated styles, however, should probably be stored with more separation, similar to their separation in the definitions. Whether this decision of separation vs. grouping will be automatic or given to the developer/user is undecided at this time.)
Keep note that it makes sense to be able to override Fusion and Vortex definitions from the same style since the style would be made for Nebula which depends on those definitions.