GNOME Bugzilla – Bug 310411
Index source selection widget should show all active sources in beagle-search
Last modified: 2008-07-28 14:18:44 UTC
There is a widget next the entry area where you can pick which types of sources to access. If you add static Index paths on the command line, it should add something like "in Files: /beagle/drichard/users" "in Files: /beagle/largo/ms" I'm attaching our users to 3 indexes sources and it's returning a LOT of data, and sometimes they know what file system contains the file and would like to narrow the search.
Filtering is now done by file type in beagle-search, rather than the backend they're from, which is really an implementation detail. Is this still an issue with the new UI?
This is still a big issue for us for sure. The types of files is great, but is a subset of the 3 static index databases they are connecting to. I would like to allow them to select and un-select sources right from the UI instead of having to go all the way back out as they do and relaunch Zenity which then kicks off the beagled again. Some of the sources are sources used by the entire City and contains hundreds of thousands of documents. Sometimes they know which of their three sources the documents is located in. By default they connect to personal, departmental and city-wide sources. The search UI should query beagled at startup and ask it which static index sources are active, and then let the users select them as needed. This would greatly aid us.
I'm not sure I am understanding your workflow exactly. You say "sometimes they know which of their three sources the document is located in." Wouldn't this imply that more often than not they don't know (and probably don't care)? In which case, you would want all three sources to be searched. What if we added a searchable keyword for searching by source? (Like how we have "ext:mp3" will search for mp3s, something like "source:citywide" would search only within the citywide index) Or maybe something like the --tag feature of beagle-build-index. I think that having some sort of advanced searching functionality is important to add at some point (bug 311060), but I don't think that just adding a specialized UI for selecting specifically from an index is a good idea. (Think of the much more common operation of a search returning an attachment to an email. You'd want to show it as a file, even though it is stored in the email index. Limiting by backend would cause you to miss this hit altogether.)
Created attachment 57965 [details] [review] one-liner to do what joe says I suggested the keyword query procedure to Dave. He wasnt happy. Using keyword search is too complicated for his users. For completeness, I am attaching the patch I emailed Dave.
Let me then change the word 'sometimes' to 'often'. Thoughts: 1) 80-90% of users won't be able to type in a command like the one proposed. They won't remember the syntax, won't key it in correctly even if they did know it. It has to be something that they can click on and that is extremely easy. 2) Right now I have had some people *stop* using Beagle because it's returning way too many documents and their documents are too many pages deep to find. If they know exactly where it is on the drive, the 3 sources are returning too much information. 3) Unless something graphical is added to the UI, I'll have to continue kicking off that ugly Zenity front end and reduce their searches by starting up beagled with reduced document sources. I wish that users had our skils, life would be a lot easier. :) If you are worried about the masses, a command line flag for those that wish to have a bit of control would be great...something like --allow-select-sources or similar. I'm attaching a mockup of an idea of what we would need here to make beagle work in the manner the user community expects...and to avoid having to force them to exit and re-enter beagle each time they want to run a query with a different source. I understand your concerns about them not seeing all documents and missing things because they have de-selected sources. It would be fine with me if when you start a search, all of the sources in the bottom of the mockup re-check themselves and then users could uncheck to reduce the total number of documents. that way at least initially they are presented on the screen. Attaching mockup.
Created attachment 58018 [details] Mockup of UI...at bottom it allows users to select and de-select sources.
Ok, I'm back on this one. (tomorrow *is* Friday Dbera) :) I found that we can query and get this from the daemon: [drichard@nas bin]$ ./beagle-info --index-info Index information: Name: GaimLog Count: 0 Indexing: False Name: IndexingService Count: 0 Indexing: False Name: Tomboy Count: 26 Indexing: True Name: Blam Count: 0 Indexing: False Name: Liferea Count: 0 Indexing: False Name: Akregator Count: 0 Indexing: False Name: KonquerorHistory Count: 0 Indexing: False Name: Kopete Count: 0 Indexing: False Name: Google Count: -1 Indexing: False Name: users Count: 3579 Indexing: False Name: lg Count: 15484 Indexing: False Name: ms Count: 14528 Indexing: False Could the UI not then look at this information and build a selection widget based on all Name:s that have a count greater than 0? In my case, it would say [All],[Tomboy],[users],[lg],[ms]. It seems like this would create a generic method that would be use to everyone, and meet our needs as well and let people be able to reduce the scope of their searches. This would allow people also to hit up just their Tomboy notes if they so desired. I'm just trying to find a way to get rid of my front-end that makes the users select sources before they enter into the UI. I would like to change it dynamically and with a mouse.
We'll see if tomorrow is indeed a Friday ;-) As for the GUI showing the sources, there are a few problems (these arent mere programming problems, but GUI/HCI decisions which are tricky): 1) The information about non-zero index-count indexes can _only_ be retrieved if beagled is already running. This is not as assumption one can make about the GUI. 2) Conversely, what if beagled is stopped while the GUI is running ? What should happen ? Anything done to deal with the above 2 cases is sure to confuse a hell lot of users if not done right!
I know that one of your concerns earlier in this issue was that people would forget to untoggle it not get everything back. Possibly then to work out that issue and also the issue of when to refresh the UI. Something this: 1) User enters search criteria and hits [Find] 2) UI checks to see if UI is running, it not tries to do so. 3) All data from all sources is returned along with Name:s of sources (Beagled is running if you get data back, obviously) 4) Name:s of sources are loaded into widget offering them the ability to reduce the number of documents in the UI by selection. It seems like since you are holding all of the documents in an array or something, that you could hold the Name: of the source that returned the hit as well and when the user does step #4 not require a hit back to beagled. It could just reduce the visible items of the array. 5) When the user does another search, the Name:s widget would reset back to [All] and repeat the same steps again.
Kinda self-explanatory, patch is against best... which we don't use anymore..
Received first hard coded patch from Dbera (thanks!). This will allow us to begin testing the work flow. I'm leaving this issue open until we find a way to merge this into the main build.
Fixed in 0.3.8. This is now handled by using the environment variable BEAGLE_SEARCH_SCOPE. E.g. BEAGLE_SEARCH_SCOPE="indexa=source:index1;indexb=source:index2" will add two entries in the drop-down list "indexa" which will only search in the static index "index1 and so on. The name of the index (e.g. "index1") can be set using the --source argument while running beagle-build-index.