Apply color theme to docs as well

[capital-G]

Motivation

Currently the documentation does not adjust to the selected Qt theme - this makes the dark themes not as usable as they could be because when opening the documentation on a dark theme one will be brightened by the light color scheme of the documentation.

Description of Proposed Feature

Currently the dark theme looks like this

I wrote a css file for the dracula theme so it can be adjusted

For each available Qt theme there would need to be a css file, but it has not to be limited by the Qt themes.

Plan for Implementation

While implementing the dracula theme I figured out that there are lots of inconsistencies in the styling.
I know that there is a heart for diverse implementations in SC but at the same time it makes it hard creating new color themes.

I would suggest writing a SASS file in which the style can easily be set for a theme - separating the arrangement from the color code in CSS.
Implementing a new theme for SC IDE/Docs can then become easier to manage.

Maybe this would have also the benefit that a more full screen friendly web version of the docs could be generated as well, see

The question is how the design should be applied when selected in Qt IDE? Maybe a simple color_theme.css gets copied/overwritten when a new theme is selected (like an additional frontend.css - this is a bit prone to errors due to the file copying but as the IDE and static HTML pages have no other way to interact maybe this is the best way? This would also allow alternatives IDEs to use a styled CSS for the docs.

[capital-G]

Actullay a refactoring of the stylesheet scdoc.css would be good

More than half of it is never used

[telephon]

Yes, some cleaning up would be a very good idea. IDE and help file renderer are not very well connected.

[telephon]

Maybe a simple color_theme.css gets copied/overwritten when a new theme is selected (like an additional frontend.css - this is a bit prone to errors due to the file copying but as the IDE and static HTML pages have no other way to interact maybe this is the best way?

There are a number of places where files are getting written to organise and keep defaults, especially in LanguageConfig, and of course for larger SynthDefs and the Archive.

In this case: if there is a write error, say due to wrong permissions, the whole thing should still work. Then, I find that this is OK. There is already a place for rendered html, so there is no new folder to be created either.

[capital-G]

I created a branch #5487 in which the stylesheet is build via SCSS, a superset of CSS.
This allows to introduce variables for e.g. colors instead of overwriting everything in the frontend.css which is messy and instead of an additional new css file the main scdocs.css (which would also include the editor.css) would be replaced.

I started by extracting all colors into variables and now want to consolidate the theme colors from around 40 to around 20(?) to make the look more consistent and creating new themes more easy.

There are two things I struggle with:

• SCSS requires a new compiler (SASS) to render CSS files - if some CSS needs adjustment all files needs to be newly compiled - should this be included in the build step (which would introduce a new build dependency) or should the buit CSS files only be included and each person who modifies a stylesheet? Both ways are not good IMO. Something along https://pre-commit.com/ would be maybe a nice addition in which git-hooks could be managed.
• Without access to sclang I do not know where SCDoc.helpTargetDir is located if it is non-default. Is this acceptable to assume defaults here?

Any thoughts and opinions on this would be appreciated

One bug i found: the theme of the code within the docs does not match the default IDE style, see

New doc code style

As is code style

Probably the classic style?

[capital-G]

Btw, by changing two css parameters the web documentation looks a lot cleaner

vs

I will propose these adjustment in a new PR as this goes beyond the color management of the style sheet

[telephon]

* Without access to sclang I do not know where `SCDoc.helpTargetDir` is located if it is non-default. Is this acceptable to assume defaults here?

If it doesn't break if it is not found there, it should be fine to assume it unchanged by default. This should be refactored in a separate step that helpTargetDir should be saved in LanguageConfig so that the path can be seen from the yaml file.

[capital-G]

So, I think I wanna go back to this, but this time in a less invasive and more sustainable manner.

The proposal is to simply skim through the CSS codebase and replace all hardcoded colors with plain CSS variables and unify them a bit while I am at it (I've already did this for the scss rewrite).

These CSS variables are then loaded/set via JavaScript. Which CSS theme to load is defined by a cookie which can be accessed/set within the QtWebEngine.

Maybe additionally there should be a way to set this from within the HTML Docs for static HTML websites as well as if one wants to have non-matching styles for docs/IDE.

[dyfer]

@capital-G thanks, this sounds like a better and a more sustainable approach. Of course the docs should still work when the help is served from outside the IDE - I personally think it would be fine if it defaults to the current theme in that case.

[capital-G]

Closed in favor of #6095