> > 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... _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
