On instances that are branded light-only, new users still start with auto, so the UI follows the device and switches to dark mode. An admin cannot set a default; each user has to change it after the first login. A similar request was made in https://community.vikunja.io/t/default-theme-environment-variable/1463.
Proposal
Add color_schema to the existing defaultsettings block, next to week_start, language, timezone etc.:
defaultsettings:
color_schema: light # auto | light | dark, default: auto
It would only set the initial value of frontend_settings.color_schema for new users. Users can still change it.
Context
Vikunja 2.7.0, self-hosted for a family. I checked the source only: frontend_settings.color_schema defaults to 'auto' in frontend/src/helpers/userSettings.ts.
Fair point, and I agree it should stay the user’s choice. This would only change the initial value – every user can still switch it, and without the setting the default stays auto. That’s the same pattern defaultsettings already uses for language, week_start and timezone, which are personal preferences too.
Why we need it:
Branding is light-only. Our instance shares one look with the other services on the server (cloud storage, mail, photos). Our colours and fonts exist only as a light variant. In dark mode the UI no longer matches the rest of the server.
Non-technical users. It’s a family instance. Most users won’t look for the setting; with auto they get dark mode just because their phone is set to it, and Vikunja looks different from every other service they use.
Today’s workaround is worse for users. Right now our reverse proxy injects a script that removes the dark class from <html>. That forces light mode even for someone who deliberately picked “Dark” in the settings. With an admin default we could drop that script and give the choice back to the users.
So the goal is a sensible starting point for branded instances, not taking the choice away. Happy to send a PR if you’d accept it.
If you’re theming, you should fix the dark theme so that it looks similar to the other apps. Forcing light mode on users who want to have it dark and vice-versa make it worse for users, both from an a11y perspective and a convenience aspect.
I agree that forcing a mode is bad – that’s actually what we’re doing today, and what I’d like to stop. Because there’s no default, our proxy removes the dark class, which overrides users who picked dark. A default would fix exactly that: everyone starts light, and anyone who needs dark for accessibility or comfort switches once and keeps it. auto is a default too, just one chosen for everyone.
A matching dark theme would be the ideal, I agree. But for a one-admin family server running several apps with different theming mechanisms, maintaining a second variant of each theme across updates isn’t realistic for us. Bulwark just added an admin policy for the colour mode in 1.16.0 for the same reason.
