Color scheme: adapt to system not working on Linux (Fedora/GNOME)

Steps to reproduce

  1. Have a light theme set on the system
    • on Fedora, this means e.g. going to GNOME Tweaks → AppearanceThemesApplications and selecting a theme from the drop-down
  2. Launch Obsidian
  3. Check that OptionsAppearanceBase theme has the value “Adapt to system”
  4. Change the system theme from a light theme to a dark theme
    • in my case, this would be Materia-light-compact → Materia-dark-compact, but I also tested this on the default GNOME theme (Adwaita → Adwaita Dark)

Expected result

Obsidian should adapt its color scheme to the system theme and switch to the dark color scheme.

Actual result

Obsidian’s color scheme remains light.

Environment

  • Operating system: Fedora 35
  • Desktop environment: GNOME 41.5
  • Windowing system: X11
  • Debug info:
SYSTEM INFO:
	Obsidian version: v0.14.15
	Installer version: v0.14.6
	Operating system: #1 SMP PREEMPT Wed Apr 20 15:37:53 UTC 2022 5.17.4-200.fc35.x86_64
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: light
	Community theme: none
	Snippets enabled: 1
	Safe mode: on

Additional information

Other applications such as Firefox and Visual Studio Code do adapt their theme to the system theme, so I think this should be doable for Obsidian as well (especially since VS Code uses Electron too).

Here are two illustrative screenshots of the problem:


Does it work if you close and reopen obsidian?

Also download and reinstall obsidian (appimage or snap)

Does it work if you close and reopen obsidian?

Seems like it does, it did no occur to me that I had to restart the app for it to work! So I guess what I’m looking for is that Obsidian should adapt to the theme immediately just like my other apps do. Obsidian also updates the scheme instantly on Windows, without a relaunch, and I would expect the same to happen here.

I have configured my system theme to change based on the time of the day, so I consider it an important feature to have my apps adapt to that setting without having to perform any extra steps.

Do you have to restart for every dark/light change, or just once to make the setting work?

Every change. Which defeats the purpose of the “adapt to system” setting for me, since at that point you could just toggle the dark/light mode via a hotkey if it’s going to require manual intervention each time anyway.

Ouch, annoying. As a workaround, you could try the System Dark Mode community plugin. I don’t know if it’ll work on your system, but I used it before Obsidian had that setting. (Er, actually I see I’m still using it — I guess I can turn it off now.)

I’ve tried that plugin before, and unfortunately it has the exact same problem on Linux, the theme only changes on restart. I believe Obsidian’s own implementation is actually based on that plugin since they specifically thanked the plugin developer in the release notes.

I have now tried reinstalling Obsidian as suggested by WhiteNoise (although Fedora uses Flatpak instead of Snap):

sudo flatpak remove md.obsidian.Obsidian
sudo flatpak install md.obsidian.Obsidian

I then created a fresh vault, and enabled the “adapt to system” setting, but the issue persists.

I also tried the same with the AppImage distribution, the problem exists with that as well. So this is most likely not a packaging-dependent bug.

To confirm that this bug isn’t just something weird in my environment, I’ve reproduced the bug on a fresh installation of Ubuntu 20.04.4 LTS (GNOME 3.36.8, X11). Changed the theme from Yaru to Yaru-dark → Firefox and VS Code adapt instantly, Obsidian does not (until after a restart).

I tested all the supported installation methods for Ubuntu (Snap, AppImage, and deb).

I hope this helps the developers in some way.

I had this issue on a Mac. Turns out I had set system appearance to light and changing it to auto fixed the issue for me.

thanks

Hi, same issue here on the same system (Fedora 36 workstation, GNOME 42.2, using Wayland).
Any solutions?

Also, I wanna commend @ecchina_ko for the excellent bug report :wink:

1 Like

I guess you could schedule a script to restart Obsidian at the same time of the day your system theme changes. This is, of course, not optimal, and could get in the way if it happens to restart just when you’re actively using the program.

1 Like

I have the same problem.

Gnome 42.2 Wayland
Arch Linux
Obsidian installed via Flatpak

I did some research, and I think I now know where the problem lies.

The Bug

While I obviously don’t have the original source code for Obsidian, I played with the development tools and the transpiled JavaScript code, and it would seem that Obsidian indeed uses the same method as the System Dark Mode plugin; specifically, it calls window.matchMedia() to get a MediaQueryList, to which it attaches an event listener for the prefers-color-scheme media feature, with a callback to a function that sets the theme depending on if the value is dark or not. Now, this would normally be all fine and dandy, except that the prefers-color-scheme feature has been broken on Chromium on Linux since 2019, specifically in the way that it does not react to the selected GTK theme – which is what GNOME and Fedora (among other Linux distributions and desktop environments) use. Since Obsidian is dependent on Electron, and Electron is dependent on Chromium, the bug also affects Obsidian.

The Fix

But wait – how does VS Code, which is also written in TypeScript and Electron, get around this on Linux? Their theme service uses Electron’s nativeTheme module, which provides an API to read and react to the system’s theme changes. It presents a general interface while performing the actual system-specific theme logic under the hood so that Electron users don’t have to do all the OS-specific handling themselves. Because of the previously mentioned Chromium bug, Electron developers have implemented a workaround for GTK themes for the module. The workaround seems like a good solution for now since Chromium developers don’t seem to be in any hurry to resolve the issue on their side.

There is still one noteworthy thing to mention. Starting from version 42 – released a few months ago – GNOME now uses the FreeDesktop settings portal for providing the user’s dark style preference for applications, which can be set by the user in GNOME Settings. Electron’s nativeTheme module does not support reading this value yet, which means that GNOME 42 users (like yoavzack and kalcifer above) cannot currently rely on that system setting for Electron applications. As a workaround, they could use this GNOME extension, which supports scheduling dark/light theme changes (I’m using it on Fedora 35; it works great). The extension changes the actual selected GTK theme, which Electron’s current workaround relies on. The dark/light preference in GNOME Settings won’t change the selected theme; instead the selected theme (Adwaita by default) simply adapts to the chosen preference if it supports it.

In Short

The solution for Obsidian would be to use Electron’s nativeTheme module instead of using prefers-color-scheme directly. This would instantly fix the issue for most Linux distros that use GTK themes, and hopefully soon for those on GNOME 42 or other very recent desktop environment version that implements the FreeDesktop settings portal. However, even the cutting-edge users will be able to benefit from the nativeModule change right now before Electron fixes their GTK integration by using the extension workaround mentioned above.

1 Like

Thanks, for digging this up. It is unlikely that we’ll use the electron’s workaround. We need broad multi-OS support and it won’t work on mobile (where there’s no electron).

However, you can write a plugin to handle this using electron/remote.

Is it not possible for Obsidian to use nativeTheme on desktop and fall back to prefers-color-scheme on mobile?

It’s possible but it won’t be prioritized.

I see, unfortunate but understandable.

I don’t have any experience in Obsidian plugin development, but since I do know JavaScript/TypeScript, maybe I’ll try my hand at it at some point (no promises, and no idea when this would be).