on Fedora, this means e.g. going to GNOME Tweaks → Appearance → Themes → Applications and selecting a theme from the drop-down
Launch Obsidian
Check that Options → Appearance → Base theme has the value “Adapt to system”
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:
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.
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.
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 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.
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.
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.
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).
