The file is opened with external application associated to the file (in this case Libreoffice), while the interface of Obsidian is still responding.
Actual result
The file is opened with external application associated to the file (in this case Libreoffice), but the Obsidian interface is frozen and remains unusable until Libreoffice is closed.
Environment
Debian Sid, evilwm, Obsidian official deb package.
SYSTEM INFO:
Obsidian version: v1.5.8
Installer version: v1.5.8
Operating system: #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-1 (2024-03-08) 6.7.9-amd64
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Additional information
First of all let me say that I am aware that this has been discussed already a few times in this forum (I searched) and that the last bug report about it (Opening attachments in external program freezes interface) mentions that you will not fix it, and I also read in the bug report that you only provide support for Gnome and KDE.
However, please hear me out. I’m currently evaluating Obsidian after realizing that Logseq is not a great fit for my way of working. So far I’ve been really impressed but this issue is really problematic. Many people on Linux are not using a Desktop Manager (DE), they are just using Windows Managers (WM). I have never encountered this issue with any other desktop applications (FLOSS or closed-source). Running things in a WM is not niche, DE like Gnome and KDE also provide their own WM. I do not know how Obsidian open external files on Linux, so it is hard to suggest anything more than trying to convince you to look into it. In the past years this has been frequently discussed in bug reports regarding electron and how xdg-open is handled for instance, to prevent blocking.
Another thing I noticed is that the menu entry “Open in Default App” available when viewing a PDF freezes entirely Obsidian and no default app is ever opened. However there is a default app configured, as I can open PDF fines with xdg-open blabla.pdf. I suspect this is the same issue manifesting itself differently.
Maybe another useful hint: “Show in system explorer” works as expected. It launches my default file explorer, SpaceFM, at the right location, and Obsidian is not freezing!
I am using Mac, I found “mind map” is the issue. I kept the preview of “mind map” tab opened, when I open the pdf, it will try to generate a mind map for it, that might coursed the issue from my side.
Thanks for sharing your thoughts Jarod!
However I also think this may have been a different issue. The problem here seems to be exclusively specific to Linux users who are not on Gnome or KDE.
I don’t think this should be done with a plugin. My hope is that the developers will be able able to spare a bit of time to look at how other electron based editors handle file opening, and more specifically how to make sure this is done in a non-blocking way for the parent process. There are several ways to do this and I believe this is well documented.
I have another problem, since I switched away from KDE to LXQt and i3: clicking on an external link (URL to Website), the link is opened twice in the browser. Trying to open it with keyboard commands only works, after manually switching to the browser. Obsidian is really the only app with this problem.
Oh, found it after checking this in the sandbox and then switching off all external extensions (sorry, should have tried this before answering here).
The just described link problem ist caused by the plugin “open link with”: obsidian://show-plugin?id=obsidian-open-link-with
I gave one last attempt at fixing this on my own as it seems this is not a priority for the devs and I found an actual workaround. Make an alias in your ~/.bashrc, ~/.zshrc, etc, with the following:
alias obsidian="XDG_CURRENT_DESKTOP=GNOME obsidian"
Reload your shell, and you’re good to go. Obsidian will open files with external apps without freezing.
Explanation:
If you’re using a WM, then XDG_CURRENT_DESKTOP is not set. If that’s the case, then electron falls back to xdg-open to open files. That should be fine, but for unknown reasons, in obsidian, it is done in a blocking way, meaning that while the external application is running, obsidian is frozen. Other electron apps doing similar things are not blocking so this is really an obsidian issue I think.
If you are using a DE, them XDG_CURRENT_DESKTOP is set to a known standard DE. For instance if you use Gnome then the value set is GNOME, when this is the case, electron will make use of the DE’s preferred file opener, which is not xdg-open but could be anything that relies on gio a low-level utility and library in the GLib world for dealing with I/O, networking, IPC, Gnome/GTK settings, etc. Somehow this works nicely with obsidian as nobody ever encountered this issue while using Gnome. The same reasoning also exist for KDE but I don’t know anything about this DE.
Solution: if you use a WM and manually set XDG_CURRENT_DESKTOP to GNOME that means that when you launch obsidian with such an environment variable set, electron will think you run Gnome. On my system it means that gio is called directly instead of xdg-open or any other file opener. Of course you need to have gio installed (on Debian, it’s in libglib2.0-bin, and could be you already have it as it is often a dependency of large GTK/GLib stuff, even if you don’t use Gnome). For sure in theory xdg-open is the proper method (as in freedesktop standards) to deal with the issue, and hopefully this will eventually be properly fixed in obsidian. In the meantime this workaround is the only elegant and least intrusive way I could figure out to make obsidian working properly with a WM.
