Theme system

[Tracer1337]

Status	Type
✅	Feature

Description

Successor of https://github.com/vocascan/vocascan-frontend/pull/101

Also includes changes from https://github.com/vocascan/vocascan-frontend/pull/110, cause I messed up my git history.

Theme-System through CSS variables. The SCSS variables are references to the css variables now.

Themes are stored in the folder public/themes. The current theme is stored in Redux and can be changed through a Redux action. Additional themes can also be mounted into the docker container.

Screenshots / GIFs (if appropriate):

Without additional themes:

With additional "amber" theme:

# docker-compose.yml
# ...
volumes:
      - ../public/themes:/usr/share/nginx/html/themes

Resolves

frontend/projects/1#card-51929616

[Tracer1337]

What needs to be done:

2 instead of an dark/light theming system we could maybe consider about multiple and also an extendable theme system like vscode have. My thoughts for the future are:

2.1 an key/value store for user settings on the backend where we store which theme a user prefers which can be overwritten per device on localstorage 2.2 . It would also be cool, if we could somehow select a custom css in the desktop app or mount custom themes into the frontend nginx docker container to select. 2.3 Maybe we could consider about dark/light implementation of each theme

[luwol03]

I would say that first a good start is to allow custom themes by just adding a css file into the themes folder (could be mounted into the frontend docker container or an dialog to import for the electron app). Then save the users preference in local storage. If nothing is selected, use the machines default for the default light/dark theme. So you need to:

• switch the toggle to a select which loads all available themes in the folder (maybe use a config variable which should be set (for a simple setup how these config options work you can take a look at my react-app-docker github repo). This system is already implemented in vocascan-frontend. With an option you may can specify available theme files)
• detect the machines default if nothing is

@noctera or what is your opinion?

[noctera]

I think implementing the basic dark and light theme with an select option is a good start. If you have some time left you can add the functionality to add custom themes to the frontend container.

However I wouldn't just replace the toggle with a select menu. I would outsource this option to the settings page.

[Tracer1337]

I think implementing the basic dark and light theme with an select option is a good start. If you have some time left you can add the functionality to add custom themes to the frontend container.

However I wouldn't just replace the toggle with a select menu. I would outsource this option to the settings page.

We could keep both the switch and the theme-selector.

2.3 Maybe we could consider about dark/light implementation of each theme

How will the FE know, which themes are mounted into the container? My first naive approaches are:

• Include a mandatory themes.json file in the mounted directory, which the FE queries and therefore knows which themes exist
• A small web-server, reverse-proxied by nginx alongside the static FE files, which automatically reads the content of the mounted directory and provides an api route which the FE queries

[luwol03]

How will the FE know, which themes are mounted into the container? My first naive approaches are

Read my message carefully. My idea was to set that as config option in the Frontend like the base url.

[Tracer1337]

How should we handle the translations for mounted themes? Fallback to the key of the theme?

[luwol03]

Can we somehow include translations if available in the themes file via comments in css at the top of the file?

Maybe the generate config script can extract them and add them to the config object.

[Tracer1337]

Can we somehow include translations if available in the themes file via comments in css at the top of the file?

Maybe the generate config script can extract them and add them to the config object.

I don't think that we need translations at all. Someone who mounts his own themes, knows what they are. So only displaying the key may be enough.

[Tracer1337]

Note to myself: Move default themes into a different directory. That way the mounting doesn't override the default themes.

[luwol03]

I don't think that we need translations at all. Someone who mounts his own themes, knows what they are. So only displaying the key may be enough.

Good point.

[luwol03]

1. Can you also add a bg color to the select component?

2. What about choosing a bit darker color as the primary color?

[Tracer1337]

1. Can you also add a bg color to the select component?
2. What about choosing a bit darker color as the primary color?

Done and Done:

We should be cautious with using a primary color as the background color for large surfaces. This may look weird with some themes (like the dark-theme now)

[noctera]

What about using a slightly darker color than showed on the other side. I think this variant would work in every theme

[luwol03]

Can you please resolve conflicts.

[Tracer1337]

Can you please resolve conflicts.

Done

[Tracer1337]

@luwol03 I think we can merge this

[Tracer1337]

Selects now look like this: