Quote:
Originally Posted by ecovisiones
Hi! First of all, thanks for this plugin — it’s a great idea and very helpful for anyone who uses Calibre + Obsidian.
I’ve been testing the latest version (1.4.1) on Linux (Ubuntu 24.04), and here’s what I’ve found regarding the obsidian:// URI flow and note creation:
What works:
The obsidian://new?... URI does work to create notes in Obsidian.
After allowing the system handler prompt in the browser once, Obsidian handles the link correctly and creates the note in the vault.
❌ What doesn’t work automatically:
webbrowser.open() opens the default browser (as expected), but requires a manual click every time to "Visit site" or confirm the handler.
Enabling the checkbox “Use Linux xdg-open command…” in the plugin does not change the behavior — it still opens the browser.
I tested replacing webbrowser.open() with:
os.system("xdg-open 'obsidian://...'")
subprocess.run(["xdg-open", ...])
Direct call to Obsidian binary with the URI
But none of these worked when executed from within Calibre, even though they work fine from the terminal.
Hypothesis:
Calibre (installed in /opt) may be running in an environment where graphical environment variables ($DISPLAY, DBus, etc.) are not inherited correctly. That prevents xdg-open or GUI apps from launching from subprocesses.
Current best option:
Returning to webbrowser.open(uri) is the most stable method. After the first browser confirmation, it works every time — but requires a manual click unless browsers allow persistent approval (not always the case).
Suggestion:
It would be helpful if the plugin’s config UI made this clearer — maybe by noting that:
The xdg-open option might not work reliably under some Linux environments.
And that browsers will always require user interaction for security reasons.
Thanks again for the great plugin, and happy to share test cases if useful!
ecovisiones
|
Thanks for the really detailed write-up — your diagnosis is essentially correct. The reason xdg-open (or calling the Obsidian binary directly) works from a terminal but not from inside calibre is that calibre's official build ships its own libraries under /opt and points LD_LIBRARY_PATH at them. Any process the plugin spawns inherits that environment, so the browser or Obsidian it tries to launch can't load the right system libraries and silently fails. webbrowser.open() tends to dodge this because it usually hands the URL off to an already-running browser. So it is an environment issue, as you suspected — just LD_LIBRARY_PATH rather than $DISPLAY/DBus.
I've put together a fix in my fork: instead of webbrowser/xdg-open, it opens the obsidian:// link through calibre's own open_url, which restores the original environment before launching. I don't have a Linux machine to confirm it on, so I'd really appreciate it if you could test it:
https://github.com/warzoo/highlights...ag/v1.8.1-beta
Download highlights-to-obsidian-1.8.1.zip (the asset, not "Source code"), then install it with Preferences → Plugins → Load plugin from file and restart calibre. Make sure "open Obsidian with the OS's command" is unchecked so the new path is used, then send a highlight — ideally Obsidian opens the note directly, with no browser step.
One quick check that predicts the outcome:
xdg-mime query default x-scheme-handler/obsidian
If that returns an obsidian*.desktop, the scheme is registered with your desktop and this should work without a browser. If it returns nothing (common with the AppImage build of Obsidian), your system can't open obsidian:// directly — in that case the most reliable option is "Write highlights directly to vault files", which skips the URI (and the browser prompt) entirely.
Let me know how it goes and I'll fold the fix into a normal release. Thanks again!