I have developed Notebook Navigator, a file explorer alternative for Obsidian with over 150 000 downloads in just over two months. Currently: clicking on links to files, folders or tags in Obsidian always open them in the built-in File explorer or built-in tag view instead of Notebook Navigator.
Proposed solution
Being able to register plugins as File explorer plugins. This could be done by adding specific metadata in the plugin.
A new option in “Files and links”: Default file explorer. A dropdown where users can choose between the built-in file explorer and plugins like Notebook Navigator.
When set to plugin, all links to files, folders and tags will be sent to Notebook Navigator instead of the built-in file browser.
Important - I want all three types to be forwarded to my plugin: files, folders and tags.
Current workaround (optional)
The only workaround is to monkey-patch the entire Obsidian UI to hijack all clicks to my plugin. Lots of other plugins do it. I don’t want to do it, and you don’t want me to do it.
My proposed solution is clean, very easy to implement, and with no side-effects in the Obsidian app.
absolutley being able to set to the default file explorer would be awesome , its a pain point at the moment especially with the breadcrumbs where it reverts straight back to file explorer. Since switching to noteebook naviagtor I physically cant bring myself to switch back theres too many QOL features that i depend on
This makes sense to me. Especially if it would allow NN (or another File Explorer style plugin) to have more access to the folders at the top of the page:
Right now, I can right click on them with NN to access some functionality, but would love to be able to left click on one and have it navigate to that folder (I’m pretty sure this is currently an API limitation but not 100%).
I also agree that this should be configurable. Opens up a lot of opportunities for conditional routing for certain interaction types.
The more open to programatic / conditional configuration the better, instead of just a changing of default preference for one plugin to handle all types of file explorer related interactions.
Don’t get me wrong, I support the idea; but there was a feature request for NN to support dev-API, and the reply was: “I like this idea, problem is Notebook Navigator is getting extremely complex”. Hopefully, Obsidian team won’t say that “Obsidian is getting extremely complex”. Surely, the scale of required changes might be different, but the irony is there.
Also, a slightly cleaner approach might be to split such options into separate ones to support multiple link handlers, e.g. two plugins can react to the same link/tag/file/etc click differently. A single “default explorer” might not be enough.
It might also look like this (or similarly on a plugin initialization):
As long as this has no appreciable effect on the current File Explorer implementation and is totally optional, I wouldn’t object. Otherwise, NO! I find the current implementation perfectly suited to my use as a text file editor.
