Hello!
I was hoping to receive some information and feedback about a potential extension to Nautilus’ extension API.
Context
-
Using remote storage locations shared over NFS or SMB are inherently slow to index. They depend on the connection speed and require the indexer to download every file locally. It can ruin user experience and make Nautilus feel like a “bad program”, even though there is nothing it can do.
-
Specific filesystems might know more about the files they contain. An example would be https://tmsu.org, a FUSE filesystem that displays files in a non-hierarchical overview based on user-defined tags. The filesystem creates a virtual folder, holding folders named after the tags one specifies. But that only allows for single tag searches. There is no possibility to express and use the extra information in Nautilus.
Issue
Conducting search operations and indexing inside these filesystems is either slow or does not take advantage of additional features in a user-friendly way.
Solution
I would like to discuss an extension to the Nautilus extension API. This would include functions to provide custom search suggestions inside of Nautilus. Extensions can register to be a SearchProvider. These can populate the suggestion list inside of Nautilus with custom items that the user can select from.
A custom extension using the new API could improve the experience for scenario 1 drastically: instead of downloading and indexing the file locally, the extension could query an API running on the remote server that provides the network share. The remote server returns a list of matching items, including data like name, path, date, thumbnail and more. This would allow the Nautilus or Indexer team to implement an official extension that could provide remote indexing data access over networks. Basically, the indexer runs on the server, provides its data on the network, and clients connected to the server could fetch the metadata from it.
Scenario 2 could leverage the new API to show an intermediate search with all tags matching the entered user query. Upon selection, the search re-populates with the items that match the selected tag. The extension could filter for queries starting with a special character (#) to differentiate cases where it will overtake the search vs. where it will ignore the search and let Nautilus handle it.
UI
Since Nautilus does not directly provide search suggestions right now, it might be necessary to extend the current UI. A viable option would be to provide a first-level search that shows the suggestions, from which the user can pick one. The picked item would then be used to show the “real” search. It can be thought of as an intermediate step or a “fake search”. A quick selection scheme to be able to use the keyboard instead of the mouse to select an intermediate item would be a solid feature. A solution could be Ctrl-1…Ctrl-0 to select one of the first 10 items.
Remarks
I have seen similar issues on the forum, but none came to a conclusion. Mostly due to OP not responding anymore.
I hope that I can gather some feedback and refine the idea to ultimately design and implement such an API. I am open and happy about suggestions, concerns, changes and other thoughts of everybody that wants to chime in!
Thank you very much!