Since performance is likely to be unacceptable with arbitrarily large numbers of
search results, we should impose a limit and only return the first n of them,
with a dialog saying something like "More than n items matched your search. Only
the n will be shown." n should be a preference that advanced users can modify if
they want (choose from a set maybe?).

In the Star Trek future, we could imagine having "next/previous" buttons or
something to show larger result sets, but that UI is complex and probably
confusing and we shouldn't try to do it for now.



------- Additional Comments From rebecka@eazel.com 2000-08-23 15:12:52 ----

It won't be trivial to determine the number of elements before returning
them.  I think this will have to be done in nautilus before displaying, rather
than anywhere else.




------- Additional Comments From eli@eazel.com 2000-10-16 19:00:36 ----

Batch-assigning QA ownership of Search Interface bugs to Josh Barrow.



------- Additional Comments From rebecka@eazel.com 2000-11-15 16:44:42 ----

We certainly don't have time to set this by preference.  Perhaps we should
just keep the hard limit set now?




------- Additional Comments From don@eazel.com 2001-01-08 15:21:39 ----

John, can you handle doing this dialog for PR3?




------- Additional Comments From sullivan@eazel.com 2001-01-08 15:36:59 ----

I'm not sure what state this is in now.

There is a hard limit for how many items Nautilus will show in a single 
directory (currently set to 4000, could change). At the moment, as far as I 
know, there is no code implemented to deal with a limit on the number of 
search results. However, the search results benefit from the 
Nautilus-wide limit (that 4000 again) and get the same UI, which is to say 
a dialog will appear right now. However, the dialog that appears right now 
was worded for the case where you're opening a directory with a zillion 
items in it, and will no doubt be confusing in the search results context 
(since users probably don't think of the search results as the contents of  
a folder).

I might be wrong, in that the search code may already be doing some 
work somewhere involving a separate limit. Rebecka, can you clarify this?

There's a continuum of improvements that could be made here:

(1) Everything the same as now, except that the dialog has wording that is 
appropriate for a search that finds too many items.
(2) Have a separate (smaller) limit for number of search results, with its 
own dialog.
(3) Make the search results limit customizable via a preference.
(4) Design/implement a UI that lets the user page through vast quantities 
of search results.

I think we need to do at least (1).

I think (1) is straightforward. (2) might require a little tricky work. (3) isn't 
very much harder than (2) but is a little more work and doesn't really seem 
that important to me. (4) is out of the question for 1.0 and might never 
actually seem worthwhile.



------- Additional Comments From rebecka@eazel.com 2001-01-08 15:59:42 ----

I've done no work on a separate limit for search.
I'd agree with you that (2) is probably the right amount of work to do for PR3.
If we agree this is the case, we should probably file a separate bug to create a 
preference for this limit in the future.




------- Additional Comments From sullivan@eazel.com 2001-01-12 11:20:11 ----

I've decided that for PR3/1.0 all we need to do is make the dialog box
explicitly handle the search results case well (i.e., solution (1) from the
above list). Making the limit separate from the standard directory limit
(solution (2)) is a significant amount of extra work without a corresponding
improvement in behavior, I think. I've written up a new bug, bug 45597, to
represent all the other, future possibilities.



------- Additional Comments From sullivan@eazel.com 2001-01-12 13:13:46 ----

I managed to implement/test this by working around bug 45596 locally, but bug
45596 still blocks verification of this bug.



------- Additional Comments From josh@eazel.com 2001-01-23 14:03:27 ----

When doing a search for type is regular file, the Nautilus interface locks up.
Reopening bug.



------- Additional Comments From rebecka@eazel.com 2001-01-23 15:29:43 ----

I'll deal with this, since I've been working with Pavel on search locking
issues.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:37 -------
Bug depends on bug(s) 45596.