Comment 35 for bug 646724

Revision history for this message
Christoph Buchner (bilderbuchi) wrote :

Just to be clear, I don't want to replace ZG, I didn't even intend to pull tracker into this (it was just meant as a technology reference, I shouldn't have mentioned it at all maybe). I'm just looking for a feasible solution to enable users to be able to find all files they would most probably search for, using unity. Seeing that this feature is powered by ZG, I see 3 alternatives:

a) manually open all files, or wait until user has interacted with all files without her being able to use unity search for said interaction in the meantime (this is the status now, and I think we all agree it's not very enticing).

b) Add an option to ZG to point to some directory (e.g. stuff in the users' extra data partition), whose contents will then be indexed _once_ by ZG. (Comment #29) This is basically an automated version of a), something like a "fast-forward" button.
The state of the index should then be not much worse than after normal usage for a long time, assuming the user will stumble over most of the files in said directory during normal usage, over time. Wildcard exceptions could be added to minimize cruft being added to the db (e.g. *~ files)
Is this a workable idea? If not, why? Are there negative performance impacts on ZG and/or unity-place-files I don't see?
Pro: tracker or similar technology does not have to be involved.

c) Write a script which, when pointed to a directory, accesses all the files sequentially, thus adding them to the ZG index as desired by the user. (comment #31) Admittedly the most hackish workaround, and just saves you the tedium of opening and closing files for a day or so, to be able to find them with unity-place-files.

To me at least, b) sounds reasonable. thoughts? alternatives?