Just adding my +1 that it would be great if Obsidian changed the theme mode without needing a restart. 
Edit: Would it be possible to trigger it at reload at least? 
I am on Fedora 36 and swich between light and dark themes with the Gnome extension “Light/Dark Theme Switcher”.
After switching theme, i relaunch Obsidian and it launches with the appropriate theme (dark or light).
A similar extension was already mentioned above. In any case, it’s not particularly useful since people in this thread are looking for a solution that does not require manual intervention when the system theme preference changes.
@ecchina_ko
Thank you for your very thorough investigation and write-up. I made a simple plugin that uses the electron nativeTheme API that you brought up, and it does fix the issue.
Note: the plugin has a bug when unloading. This doesn’t affect the main functionality, but I won’t be submitting the plugin to the official list for now. This means you’ll have to install it manually (more info in the repo readme.)
5 Likes
Thank you very much for implementing the solution! I can confirm it works on my machine as well.
Would you consider adding this to the System Dark Mode plugin? It should be possible to check for the user’s OS and run the relevant code.
will be fixed 1.0.1
2 Likes
I think this thread should still be kept open for the purposes of tracking the status of the feature for the users on newer Linux distros that implement the system dark/light mode preference via the FreeDesktop portal. As I have mentioned earlier in this thread, this issue won’t be resolved for people who are on more recent distros, or in other words, “adapt to theme” will remain broken for them even after Obsidian has implemented the nativeTheme feature. At least until the issue is resolved on Electron’s side (or alternatively, on Chromium’s side).
While it is once again an upstream issue, I am sure people will still be coming to the Obsidian forums looking for a fix – this thread has already at least three people reporting the issue on Fedora 36, for which the “adapt to system” feature will remain broken! The amount of people on more recent distros is only going to increase over time – as will the amount of distros that implement the FreeDesktop preference, since it is the first and only actually standardized dark/light mode feature for the Linux desktop.
To my knowledge, currently at least any distro that uses GNOME 42 or KDE Plasma 5.24 (or newer) will use the FreeDesktop color scheme preference.
2 Likes
ok!!!
Hey all, just to document it, I was seeing a similar issue on a fresh Fedora 37 install with Gnome 43, and the Obsidian AppImage on version 1.1.9
I am also using the Night Theme Switcher extension, that @ecchina_ko mentioned (thanks btw for the awesome work on providing all this info), and its default behaviour changed.
The extension changes the actual selected GTK theme
On GNOME 43 this is not true anymore (at least not for me), and you have to manually tell it to change the gtk-theme. Explicitly telling Night Theme Switcher to set the theme resolves the issue for me.
1 Like
Yeah, the developer of the extension changed the default behavior as the built-in dark mode is now the preferred method for theme switching. This is due to the fact that some applications may not behave properly when forcing a GTK theme change on them, whereas utilizing the FreeDesktop settings portal is opt-in for applications.
Somewhat related: Fedora 35 went EOL last month. This means that currently all supported Fedora releases have the system “Dark Mode” setting built-in – which won’t work (out-of-the-box) as expected in Obsidian when “Adapt to system” is enabled for the color scheme. The GTK theme will have to be switched, either manually (e.g. via GNOME Tweaks) or in an automated way (e.g. via the aforementioned extension).
Good news: the upstream bug in Chromium has finally been fixed, and will be included in Chromium 114.
Since Electron follows the stable release schedule of Chromium (Chrome), the fix should arrive in Electron 25.0.0, which will be released on May 30, 2023.
I don’t know how Electron will handle this change in the nativeTheme API, as they mysteriously closed their own issue a week ago. However, I’m pretty sure they won’t be needing their GTK theme workaround anymore, as Chromium’s fix includes GTK/QT theme fallbacks for distros that don’t yet support the FreeDesktop portal.
2 Likes
This remains broken Fedora 38 / GNOME 44, even when using the latest Electron release. This is because Electron has not adapted their API to the fix Chromium made on their side. This means the old workaround is still in place and prevents e.g. the dark mode toggle on GNOME from working properly. More details can be found in this issue. Unfortunately, the Electron issue has been closed for months for an unknown reason, and they haven’t been responding to comments from users and app developers (including the VS Code team).
1 Like
The fix for this has finally landed in Electron 25.8.4:
It has also been merged to the Electron 26 and 27 branches, so those will eventually have releases with the fix as well (probably soon).
To summarize: after this fix, Obsidian’s “adapt to system” theme setting should work out-of-the-box on modern distros that use the XDG portal, and no workarounds should be needed from the user’s behalf anymore.
@WhiteNoise I think this thread can be closed after Obsidian updates their Electron dependency to a version that has the fix. 
it will at some point.
I’m on Fedora 39 with GNOME 45.1 and still have the same issue. I have installed the gnome extension “Night Theme Switcher” and every app switches them apart from Obsidian.
Obsidian is set to Adapt to system
1 Like
Can confirm. I’m on Fedora 39 with Gnome 45.1, and it’s not switching. Obsidian is also not adhering to the Gnome setting. Gnome is set to dark, Obsidian to adapt, but it stays light even after a restart.
2 Likes
1 Like