After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310411 - Index source selection widget should show all active sources in beagle-search
Index source selection widget should show all active sources in beagle-search
Status: RESOLVED FIXED
Product: beagle
Classification: Other
Component: General
0.0.x
Other Linux
: Normal normal
: ---
Assigned To: Beagle Bugs
Beagle Bugs
Depends on:
Blocks:
 
 
Reported: 2005-07-14 20:48 UTC by David Richards
Modified: 2008-07-28 14:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
one-liner to do what joe says (711 bytes, patch)
2006-01-23 21:08 UTC, Debajyoti Bera
none Details | Review
Mockup of UI...at bottom it allows users to select and de-select sources. (24.65 KB, image/png)
2006-01-24 15:06 UTC, David Richards
  Details

Description David Richards 2005-07-14 20:48:31 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.
Comment 1 Joe Shaw 2006-01-23 19:22:35 UTC
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?
Comment 2 David Richards 2006-01-23 19:57:06 UTC
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.
Comment 3 Joe Shaw 2006-01-23 20:23:39 UTC
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.)
Comment 4 Debajyoti Bera 2006-01-23 21:08:15 UTC
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.
Comment 5 David Richards 2006-01-24 15:05:07 UTC
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.
Comment 6 David Richards 2006-01-24 15:06:00 UTC
Created attachment 58018 [details]
Mockup of UI...at bottom it allows users to select and de-select sources.
Comment 7 David Richards 2006-02-23 21:46:38 UTC
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.
Comment 8 Debajyoti Bera 2006-02-23 23:58:10 UTC
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!
Comment 9 David Richards 2006-02-24 14:10:38 UTC
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.
Comment 10 Kevin Kubasik 2006-09-16 05:24:49 UTC
Kinda self-explanatory, patch is against best... which we don't use anymore..
Comment 11 David Richards 2007-12-12 18:05:31 UTC
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.
Comment 12 Debajyoti Bera 2008-07-28 14:18:44 UTC
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.