New users will be totally oblivious to what this means.
It doesn't matter-- replace my text with your hypothetical progress bar. It's still clearly better to make the user wait and watch the progress bar _only_ when they finally do something with the search plugin than it is adding several orders of magnitude more load time to Pd for something many people may never use.
I am confused. I thought that the search plugin can be used both in the browser as well as when creating objects (as in auto-completion). If former, I can see your point to an extent. If latter, then I heartily disagree.
When a new user picks up pd (or in this case pd-l2ork, as was the case this summer with 30+ 5th-12th graders) you want things to just work.
Search-plugin does work && it indexes at startup: yay! Search-plugin does work && it indexes at first search (or first opening of search-plugin): yay! Search-plugin does not work && it indexes at startup: Pd sucks! Search-plugin does not work && it indexes at first search (or first opening of search-plugin): Search-plugin sucks!
Thus I conclude the proper place for the indexing is not at startup.
Again, I am lost. Why would it not work? If it is also auto-completion (which I think it should be, otherwise why go through all that trouble just to have it in a browser), then why would it not ever work?
I just went through problems with Gnome 3 trying to run a bunch of tracker-
- services to index my harddrive and blowing up cpu usage, so I speak as a
user when I say that I don't like that design.
It's all in the implementation. We're not searching the entire drive but a very limited set of folders...