GUI: allow user CSS

[gzotti]

Description

This introduces a way to allow users to set a different CSS (style sheet) for GUI elements.

This can be used to make brighter GUIs for sunlit screens (which we always recommend to avoid), or dark mode/reversed text, or whatever color scheme people may have in mind.

The idea is to copy the defaultStyle.css, rename it and edit whatever users want to change. No, absolutely no guarantee can be given that a user-changed stylesheet will look usable or will work if items are missing/misspelled.

I do not intend to add an interactive CSS editor, color picker or other high-priced stuff. For now, this is to be an advanced feature for users willing to hack into CSS. A chapter in the SUG describes the usage. Another PR could provide light/extra-dark themes or interactive user configuration (CSS file selection in Config dialog etc.).

Fixes #678, #1624, #2763

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 10
• Graphics Card: irrelevant

Copy either funkyStyle.css.txt or brightStyle.css.txt to your user directory.
Here are refined, finalized files for a "daylight mode":
daylight.css.txt
daylightHtml.css.txt

Remove .txt from the filename. Then in Stellarium, open the script console. Run this script:

core.setGuiStyle("daylight");

Changes will immediately take effect. GUI will appear brighter than usual. With the funkyStyle, you may puke. Sorry, this is a technical test.

This script line can be placed in the user's startup.css to set a customized default.
Alternatively, a command-line option --gui-css style can be used to launch with a customized style.css. This can also point to a file in a subfolder like --gui-css data/myFavorite pointing to data/myFavorite.css

• I added a signal "guiStyleChanged" to which dialogs must be connected.
• hardcoded style changes scattered in the code have been replaced by proper entries in normalStyle.css.

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

This is an automatically generated QA checklist based on modified files

[10110111]

No, absolutely no guarantee can be given that a user-changed stylesheet will look usable or will work if items are missing/misspelled.

What about compatibility guarantees? Is a stylesheet supposed to work correctly on a newer version of Stellarium that the one for which it was created?

[alex-w]

What about compatibility guarantees? Is a stylesheet supposed to work correctly on a newer version of Stellarium that the one for which it was created?

Until changing inner names and labels for UI elements - of course it will works

[10110111]

That's the point: are tying our hands to provide backwards compatibility in the future?

[gzotti]

Stellarium could include a copy of the currently used CSS in each package. Users will have to take care of changes between versions. Of course, our CSS is evolving really veeery slowly, so chances are high that it remains compatible. But we should not give any guarantee or committment.

[alex-w]

That's the point: are tying our hands to provide backwards compatibility in the future?

Well, the style can be loaded as additional to the exists one (currently - replacement) and we changes inner names... very rare. So, probability of compatibility is very high, but we can't guarantee it.

Obviously and probably on next step it can be 2 well-formed CSS files within Stellarium's resource file and selector of the theme in GUI (some dropdown list, like "Dark" (default), "Light", "Custom") to switch between CSS files. Of course it require restore styleChanged() infrastructure (notification/signal/slot) to apply the theme on-the-fly.

[gzotti]

Sure. It depends on what we want to allow or offer, GUI-wise. We could provide 3 differently toned settings, plus "custom..." with a file chooser. Who wants to do that?

[alex-w]

We could provide 3 differently toned settings, plus "custom..." with a file chooser. Who wants to do that?

No, 2 differently toned settings + "custom..." - one settings we had have already. ;) Maybe @martinber can help us here?

[martinber]

Hello,

Sorry, this looks like too much for the time I can dedicate to this. If I'm not wrong, doing a light theme that looks consistent and nice is not easy since there are things that cannot be modified by CSS.

One of them is the icons. We should provide a light version of them (and provide a way for the user to change this), or we should export the icons as SVG (but I dont trust that the SVG shadows/glows will work, so we should investigate if CSS/Qt drop shadows can be used instead)

The other is there could be small things everywhere, I imagine things like for example text might become the same coloas the background in some cases, and that 'rendered' things will be hard (the world map location chooser, and maybe plots)

[gzotti]

We could provide 3 differently toned settings, plus "custom..." with a file chooser. Who wants to do that?

No, 2 differently toned settings + "custom..." - one settings we had have already. ;)

Sure. "Default" is what we have now and prefer. Still, in the chooser, it is 1 of 3 presets.

• Default
• Light
• Dark
• Custom...

[gzotti]

Hello,

Sorry, this looks like too much for the time I can dedicate to this. If I'm not wrong, doing a light theme that looks consistent and nice is not easy since there are things that cannot be modified by CSS.

Yes, fully understand.

One of them is the icons. We should provide a light version of them (and provide a way for the user to change this), or we should export the icons as SVG (but I dont trust that the SVG shadows/glows will work, so we should investigate if CSS/Qt drop shadows can be used instead)

Never tried that idea, sounds interesting.

The other is there could be small things everywhere, I imagine things like for example text might become the same coloas the background in some cases, and that 'rendered' things will be hard (the world map location chooser, and maybe plots)

There are things not yet defined in the CSS. As said, if users configure their GUI to death, it's not our fault... But surely SB will ask for documentation. Yes, me too. Given that this was developed mostly before 2010, we have none of this luxury.

We could start with what I had originally in mind, just one user setting activated in scripting or command-line argument, and if SB provides a well-tuned dark or light theme, we could include that.

Another idea is to allow only some changes. As I understand, CSS means you can override styles by just loading another. So, what happens if we fix some elements and just provide main entries for QWidgets and other major elements? OTOH this gets rapidly becomes a management nightmare. Better give one structure and let users do whatever they want.

What I admit is that sometimes the bottom buttons are hard to see in the disabled state. The gray button background may have to become brighter, or we need some other means to increase contrast against the background. How could I use CSS to set that?

[alex-w]

• Default
• Light
• Dark
• Custom...

But... Default === Dark

[gzotti]

• Default
• Light
• Dark
• Custom...

But... Default === Dark

It can become even darker, with mid-gray characters on dark-gray windows. ... But more users asked for a bright mode, yes.

[gzotti]

Last commit message should have been SUG:...

I think it's ready for a test or improvements by your own ideas.

[gzotti]

New daylight css files in the PR description.

[alex-w]

It’s maybe strange, but I think this feature may be added into version 1.1 as “hidden feature” (described in the SUG).

Is it really need to copying CSS files? Maybe just add the links to files in the repository in the SUG?

[gzotti]

Hidden feature (like the fonts) is OK for me. The CSS files are small. It may be easier to have them installed, but if you want we can just place links into the SUG. OTOH, how can we guarantee that the CSS fitting to the installed version will be downloaded?

[alex-w]

OTOH, how can we guarantee that the CSS fitting to the installed version will be downloaded?

Why we should guarantee it? If we put the link to files in stellarium-stable branch, then we'll propose same files as in the latest release.

[gzotti]

OK, I see it as less user-friendly but we can restrict this for now to getting CSS files for the current version. What are the proper links?

[alex-w]

OK, I see it as less user-friendly but we can restrict this for now to getting CSS files for the current version. What are the proper links?

https://github.com/Stellarium/stellarium/blob/stellarium-stable/data/gui/normalStyle.css and https://github.com/Stellarium/stellarium/blob/stellarium-stable/data/gui/normalHtml.css

P.S. In any way after installing the new version of Stellarium we cannot guarantee compatibility custom CSS from previous version.

[gzotti]

@alex-w any further changes, or is it OK for you?

[github-actions]

Hello @gzotti!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

[freebrowser1]

I tried this and it worked on Stellarium 0.23.2 (see also #3333).
Using a startup.ssc in the scripts folder of Stellarium with core.setGuiStyle("daylight"); where daylight.css is stored in the user directory of Stellarium does work !

User dir: macOS: /Users/<user>/Library/Application Support/Stellarium/daylight.css
Linux: /home/<user>/.stellarium/daylight.css.