Create themes

[joernweissenborn]

As @tenleftfingers pointed out, there should be a way to theme stuff aka provide smaller colour palettes named after a popular tv series and movies.

what needs to happen:

• color palettes be defined
• appropriate lcars-COLONAME-SHIPNAME-bg classes need to be created

[jrwarwick]

I would like to propose the idea of having a more semantic design (which, in-universe, is an obvious implied design principal, but in practice, I realize they just needed it to seem/feel that way and were not always consistent in the set building and decoration). Have a more abstract set of conceptually-named palette slots such as:

• Primary (Element/Function)
• Secondary
• Tertiary
• Information
• Caution/Warning
• Alert
• Meta

Or perhaps even in an implied matrix of concept classes, each intersection/combination mapping to a color. Other UI concepts could be expressed as well (although some of these would be expressed also, or instead, in geometry and layout) : Input vs Output, sequence requirements/spec, Enabled vs Disabled, New vs Old, Target vs Actual

Then each "theme" could be a different css file, like:

• css/lcars-tng-enterprise.css
• css/lcars-voy-voyager.css
• css/lcars-ds9-defiant.css

Which would handle mapping the specific colors to each of the conceptual classes above. This perhaps would have an added bonus of easily using diff tools to summarize and track differences between themes.

[dthv]

Then each "theme" could be a different css file, like:

• css/lcars-tng-enterprise.css
• css/lcars-voy-voyager.css
• css/lcars-ds9-defiant.css

Which would handle mapping the specific colors to each of the conceptual classes above.

One would actually need more than one stylesheet for some series. Especially TNG develops LCARS a lot and there are also changes within DS9 and Voyager.

For a start, much of TNG uses rather sober colours with husk for primary elements, with danub, periwinkle and blue-bell. But there are also lighter settings with atomic-tangerine or neon-carrot and some hopbush. LCARS tend to get bluer in later TNG with the yellow and orange colours as highlights.

DS9, however, introduces some really colourful LCARS setups with all combinations of red, pink and blue – while the Defiant sports a more blue/yellow theme akin to Voyager.

[joernweissenborn]

Yeah, basically one style sheet needs one per season. I think there are 2 options.

First one is to create classes like lcars-tng-s1-light-blue.

The second one is to create semantic classes like lcars-light-blue and then have different options by import a style sheet like lcars_tng_s01_colors.css which defines them.

The first approach allows to mix the schemes, the second one to interchange them easily. What do you guys think is more important?

[dthv]

I think the method proposed by @jrwarwick would be best, as it is semantic. Just classes like lcars-primary-color, lcars-secondary-bg and so on that are defined with different stylesheets like, indeed lcars-tng-1-color.css. This stylesheet would then define the colours.

It would also be cool to make effects more or less configureable. Either by hardcoding 'partners' to each color or by introducing another class (lcars-tertiary-effect-bg), the latter being preferred.

[joernweissenborn]

Ok, thats ok with me, if @jwarwick is ok.

I suggest open a PR and implement the solution @dthv :D

Am Mo., 19. Okt. 2020 um 21:34 Uhr schrieb dthv notifications@github.com:

I think the method proposed by @jrwarwick https://github.com/jrwarwick would be best, as it is semantic. Just classes like lcars-primary-color, lcars-secondary-bg and so on that are defined with different stylesheets like, indeed lcars-tng-1-color.css. This stylesheet would then define the colours.

It would also be cool to make effects more or less configureable. Either by hardcoding 'partners' to each color or by introducing another class ( lcars-tertiary-effect-bg), the latter being preferred.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/issues/17#issuecomment-712395518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARG7QL6C3DHHPQXLQVZKELSLSICRANCNFSM4JINXG2Q .

[dthv]

Sadly, I do not have a glimpse of a clue on how to do that with stylus. Sorry. :-/

[joernweissenborn]

If you know CSS , then Stylus is easy. Just see it as CSS in a Python like syntax. Then you run a program (in this case gulp) which translates stylus files to CSS, It's really worth learning if you do web stuff.

Am Mo., 19. Okt. 2020 um 22:16 Uhr schrieb dthv notifications@github.com:

Sadly, I do not have a glimpse of a clue on how to do that with stylus. Sorry. :-/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/issues/17#issuecomment-712416895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARG7QJMNCFHFY5HA4KYBALSLSNAXANCNFSM4JINXG2Q .

[joernweissenborn]

just look here: https://stylus-lang.com/

Am Mo., 19. Okt. 2020 um 22:42 Uhr schrieb Jörn Weißenborn < joern.weissenborn@gmail.com>:

If you know CSS , then Stylus is easy. Just see it as CSS in a Python like syntax. Then you run a program (in this case gulp) which translates stylus files to CSS, It's really worth learning if you do web stuff.

Am Mo., 19. Okt. 2020 um 22:16 Uhr schrieb dthv <notifications@github.com

:

Sadly, I do not have a glimpse of a clue on how to do that with stylus. Sorry. :-/

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/issues/17#issuecomment-712416895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARG7QJMNCFHFY5HA4KYBALSLSNAXANCNFSM4JINXG2Q .

[jrwarwick]

Yes, I definitely prefer the use of semantic css class names (more or less as in my prior post), and see that it makes sense to have the schemes (and thus the final compiled css files) named per series and season.

@dthv would you describe a little more your suggestion for the configureable effects? Do you mean the color briefly displayed by buttons while they are in a pressed/active state? And as far as configureability, the pairings would be defined differently just for each scheme, right?

[dthv]

It's really worth learning if you do web stuff.

I don't. But I'm willing to look into it. Please just don't expect quick results. There won't be. ;-)

Do you mean the color briefly displayed by buttons while they are in a pressed/active state? And as far as configureability, the pairings would be defined differently just for each scheme, right?

Yes, and yes. Yet, while we're at it, I'd like to introduce highlight as another, say, state, leading to the following list of possible states:

• standard being how the element is normally displayed
• highlight for when the element shall drag attention on itself
• active to react on a user's input (e.g. pressing a button)

An implementation of this would involve JS to change classes etc. on highlight, but I think it's doable in priciple.

My take on it would be to use only the semantics from @jrwarwick above and then let the stylesheet define:

• what the standard colour of a primary/secondary/etc. element would be
• how such an element looks like when the system highlights it for ease of recognition (e.g. a send button highlighting when a user is filling in a form)
• the element's colour when it's pressed

On that note: Is it possible to change the entire stylesheet on a moments notice to introduce an Enterprise E Red Alert effect, changing the whole appearance of the LCARS entirely (and paint it red, pun intended)?

[joernweissenborn]

Hmm, I personally like the fact that for most things LCARS is a stylesheet only. When you add JS, like it was done with audio, please make sure it is opt-in and people can continue to use it as just a stylesheet.

Am Di., 20. Okt. 2020 um 19:35 Uhr schrieb dthv notifications@github.com:

It's really worth learning if you do web stuff.

I don't. But I'm willing to look into it. Please just don't expect quick results. There won't be. ;-)

Do you mean the color briefly displayed by buttons while they are in a pressed/active state? And as far as configureability, the pairings would be defined differently just for each scheme, right?

Yes, and yes. Yet, while we're at it, I'd like to introduce highlight as another, say, state, leading to the following list of possible states:

• standard being how the element is normally displayed
• highlight for when the element shall drag attention on itself
• active to react on a user's input (e.g. pressing a button)

An implementation of this would involve JS to change classes etc. on highlight, but I think it's doable in priciple.

My take on it would be to use only the semantics from @jrwarwick https://github.com/jrwarwick above and then let the stylesheet define:

• what the standard colour of a primary/secondary/etc. element would be
• how such an element looks like when the system highlights it for ease of recognition (e.g. a send button highlighting when a user is filling in a form)
• the element's colour when it's pressed

On that note: Is it possible to change the entire stylesheet on a moments notice to introduce an Enterprise E Red Alert effect, changing the whole appearance of the LCARS entirely (and paint it red, pun intended)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/issues/17#issuecomment-713024753, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARG7QM5OXEPMRCF35JE3HDSLXC6ZANCNFSM4JINXG2Q .

[dthv]

Definetly. Nobody likes JS, anyway. ;)

[jrwarwick]

@dthv I think I have you (at least partially) covered for that last request for Red Alert effect: https://htmlpreview.github.io/?https://github.com/jrwarwick/lcars/blob/add-module-mode/lcars/index.html#audio_section (wip source: https://github.com/jrwarwick/lcars/tree/add-module-mode )

As Joern said, this would strictly be an optional module, disabled by default. Implementation so far requires a modern enough browser to handle css filters. It worked pretty well on chrome on desktop and android for me. Not flawless, though. Try it out, if you like, and let me know if you have suggestions to improve. There is a RED ALERT button in the buttons demo section to toggle "red alert" "mode".

[dthv]

VERY nice! I'd love to see that implemented (again, as optional and disabled by default). Worked good on Firefox as well (not flawless, though, as within red alert mode there appeared a red box downmost of the page).

Still, even in red-alert mode one should be able to see which element is primary/secondary/tertiary function and so on. One would need different hues of red (and white/grey, cf Nemesis). :slightly_smiling_face:

[jrwarwick]

Here is a more proper CSS-only red alert: https://htmlpreview.github.io/?https://github.com/jrwarwick/lcars/blob/add/red-alert-css/lcars/index.html To activate, click the snippet of code at the bottom of the Colors section, or click the red-alert class name in the SVG feature guidance. It doesn't have the bugs you mentioned, allows for more control over accents and grades of red, and straight greys. Works strictly on red-alert class on the body tag (and also "disable/stand-down" is just removing the class).

[dthv]

When I click said links in your preview, the page reloads and shows True. Using Firefox 83.0 (64bit) on Linux.

[jrwarwick]

I just took a look and got a dfferent set of errors, but it looks like that htmlpreivew feature has reached some resource consumption rate limits :( I suppose that will eventually reset and the page load will work. Otherwise you will have to just download and serve locally. Perhaps someday we can set up our own preview tool or maybe github actions can help with this.