To reproduce:
(1) Launch Nautilus
(2) If necessary, change the search preference in the user level settings dialog
to "search for files by name and attributes"
(3) Press Find button
(4) Change the criterion-type popup (first one) from "Name" to "Last Modified"
(5) Press "Find Them". This will do a search for all files modified today.

Note that after awhile the sidebar says "search results, 0 items". I find that
every search by date, with any of the options specified (today, yesterday,
within X days, etc) all find 0 items.

(By the way, the throbber never stops throbbing also. This is a separate bug,
already written up as bug 43245)



------- Additional Comments From rebecka@eazel.com 2000-10-20 15:00:47 ----

I just tried this one out (search by modified  8/25) and got a whole bunch of 
results.  My guess is that it would be a medusa problem, rather than a 
nautilus one.  On that note, how old is your index?
The one I used was finished October 18th at 15:33.




------- Additional Comments From sullivan@eazel.com 2000-10-20 16:00:58 ----

Good point; my index was old, probably old enough that all of the searches I
tried were looking for something newer than the index.

This is still a problem though, since users' indexes might be old also. Maybe we
should refuse to start a search if the index is more than ??? (a day?) old. This
seems like an especially big problem with the search-by-date feature, since
often people will search for things they modified today, and if their index
isn't very up-to-date it will often not find what they're looking for. If the
fallback slow search worked that might solve the problem. If not, I think we at
least need some feedback to the user in cases like mine where the index was old
enough to guarantee no results.



------- Additional Comments From darin@bentspoon.com 2000-10-20 16:23:31 ----

I think this is a tricky issue, so I am giving it a high priority.



------- Additional Comments From rebecka@eazel.com 2000-11-02 15:25:30 ----

We'll have to start here with a design.  I'd love to get to talk to Arlo and
John about some ideas here.

I think the right thing is probably to allow all searches, but to give
the user a warning when their search is newer than their index, along with the
option to reindex at that point.  The details definitely need to be worked on
though.




------- Additional Comments From rebecka@eazel.com 2000-11-09 13:46:13 ----

Here are the results of my conversation with arlo, about how to approach this
problem:
1.  If the date requirement is so new (files modified today) that the index is
old enough to not possibly return any results, give a warning dialog with the
option to reindex
(Still need dialog wording)
2.  If the user does not have the "do slow complete search" preference on, tell
the user how new the index is, and that files newer than that won't be included
as search results
3.  Check if files still satisfy the search results for attribute searches
before returning them.  

About 3, we should probably make medusa responsible for this, but that ends up
being inefficient, because nautilus will find out those same attributes again
before displaying the file.



------- Additional Comments From rebecka@eazel.com 2000-11-09 13:47:32 ----

About 2, this should be a note in the sidebar?




------- Additional Comments From sullivan@eazel.com 2000-11-09 14:10:35 ----

Rebecka and Arlo's steps 1-3 seem reasonable to me. Some notes:

Conceptually, (2) should only come into play if the search criteria might miss
something (but not guaranteed to miss everything, as in 1) based on the index
date. However, this is technically always the case, since the index will always
have been created at some point in the past. This leads me to believe that we
probably always want to display a disclaimer about the search results if "do
slow complete search" is off -- not just for the date-based searches, but for
all searches. The disclaimer would mention the index date/time. It could maybe
appear in the sidebar, though the vertical format of the sidebar makes this
problematic. Maybe we need to reserve a line of the list view for this, or above
the list view, or something? Of course, some such locations would be much harder
to implement than others.

(3) should apply for file name searches too (not just "attribute searches"), but
maybe the way the code is structured that mistake could never be made?



------- Additional Comments From rebecka@eazel.com 2000-11-09 14:31:56 ----

I agree we sullivan on his points about (2) and (3).  Perhaps I should have been
more clear that these things should apply to all searches, not just date
modified searches.  



------- Additional Comments From rebecka@eazel.com 2000-11-15 13:03:18 ----

part one of this bug has been completed.




------- Additional Comments From rebecka@eazel.com 2000-11-15 13:32:04 ----

Note that part 3 may have performanceproblems when doing large searches




------- Additional Comments From rebecka@eazel.com 2000-11-16 17:22:37 ----

Part 3 is complete; I'd like some design help about where the "warning about 
indices being possibly out of date" should go.




------- Additional Comments From arlo@workthatmouse.com 2000-11-16 18:16:09 ----

I'll be in Friday, we can go over it if you'd like.



------- Additional Comments From rebecka@eazel.com 2000-11-21 23:49:31 ----

*** Bug 43913 has been marked as a duplicate of this bug. ***



------- Additional Comments From rebecka@eazel.com 2000-11-30 13:47:51 ----

Arlo suggested that the warning should be part of the status bar.
The status quo for the behavior for the status bar seems to be that messages
placed there disappear after 5 seconds.  Do we want to have the status bar
filled with this message the entire time the user is viewing the search
location?  It seems like 5 seconds is not enough time for anyone to see the
message, but I feel uncomfortable about leaving permenant spam in the status
bar.  (permenant while viewing a single location, of course)






------- Additional Comments From sullivan@eazel.com 2000-11-30 15:11:36 ----

Hmm, using the status bar for this doesn't seem good to me for a couple of
reasons. 

(1) As Rebecka said, messages in the status bar go away automatically after a
few seconds. We might consider rethinking this post-1.0, but it seems like a bad
idea to to so now, because I suspect doing so would cause of a lot of
ripple-effect bugs & changes. And having the "index is xxx old" message vanish
after a few seconds seems bad.

(2) The text in the status bar will be overwritten as soon as the user does
something else that causes text to appear there (like drag through a menu item,
move the mouse over a toolbar button, or select a file). The "Hey, you're index
is old so your results might be lame!" message seems too important to have it
vanish so easily, with a strong possibility that the user never noticed it.

Unfortunately, I have no brilliant idea about where to fit this text in the
current layout either. Putting it in the status bar and having it vanish after a
few seconds is certainly better than nothing, so we might end up doing that just
because it's too hard to find a better place to put it.



------- Additional Comments From rebecka@eazel.com 2000-12-01 11:07:58 ----

Here are some places to put the notice, none of which are "brilliant"
1.  the status bar and have it disappear, although maybe we could inccrease the
timeout to 10 seconds hoping that might give people a chance to read the 
message.
2.  the sidebar, although the language descriptions of the search are already
long and so the sidebar will be quite crowded and there isn't architecture in
place to do this kind of thing nicely
either
3.  the view itself, as either the first or last line.  I think this is a bad
idea ui wise, and also from a code difficulty standpoint since we will have
to either have a fake list entry, or pack the list itself in a larger widget,
both of which are nontrivial.

If we can't come up with something better in a few days, I'd like to suggest we
go with possiblity number 1.




------- Additional Comments From arlo@workthatmouse.com 2000-12-01 11:10:35 ----

What if we stuck it in the status bar 'till the next action that got rid of it took 
place (rather than a time-out) and also stuck a 16x16 alert icon in front of 
it.  The icon might draw the users attention to it, whereas plain text 
probably wouldn't do the job.



------- Additional Comments From rebecka@eazel.com 2000-12-01 11:20:11 ----

I think the alert icon is doable, and might do well to attract users
It wouldn't be trivial to implement, but it would be much less likely
to cause new bugs than removing the timeout property of the status bar
message.  
See (1) of sullivan's last comment about why removing the timeout is a 
risky sort of thing to do. It involves adding new notifications that
are tricky to get right.



------- Additional Comments From sullivan@eazel.com 2000-12-01 12:07:01 ----

Increasing the timeout to 10 seconds or so seems OK to me, though making it
permanent seems too risky. (Even increasing it to 10 seconds may make us notice
other places where a deliberately-temporary message lingers too long, and cause
us to want to fix those by clearing the text in certain situations.) Adding a
little alert icon seems good from a UI point of view but bad from a new-feature
point of view. Right now the status bar mechanism is mostly in Bonobo, and it
will definitely not be straightforward to get it to display an icon as well as
text. My vote right now would be to do a text-only solution in the status bar
and improve it further post-1.0.

Another possibility (in addition to the ones Rebecca listed) is to have a
index-status line always present in the view, either entirely above or entirely
below the list (rather than as its first or last line). However, this is
probably even riskier to implement than the already-too-risky
replace-first-or-last-line-of-list solution, because right now the search list
view inherits the layout of the view from regular list view, and this would have
to change if we wanted to add another widget to the display.



------- Additional Comments From rebecka@eazel.com 2000-12-04 15:15:53 ----

I'm going to add a status bar message and up the time to 10 seconds.
I don't love the idea, but we haven't come up with any alternatives that will
work and not be new feature, so  I'd like to defer the task of making the ui
for this feature clearer post 1.0.  If there are any strenuous objections, speak
up in the next day or two.





------- Additional Comments From arlo@workthatmouse.com 2000-12-04 15:19:52 ----

Is adding the icon really that hard to do? (meant as a question, not to be 
mean. :-)



------- Additional Comments From sullivan@eazel.com 2000-12-04 15:41:05 ----

Yes, adding an icon is probably hard. 

See my earlier comment: "Adding a little alert icon seems good from a UI 
point of view but bad from a new-feature point of view. Right now the 
status bar mechanism is mostly in Bonobo, and it will definitely not be 
straightforward to get it to display an icon as well as text."



------- Additional Comments From rebecka@eazel.com 2000-12-06 11:04:53 ----

I am taking the big leap of adding the message to the status bar, and changing
the current timeout.  I wish there were something better we could do,
but it doens't seem realistic to spend the time thinking of one.
I'll file a bug to be deferred about the poorness of this idea.




------- Additional Comments From josh@eazel.com 2001-01-22 17:53:04 ----

Marking verified.

Josh



------- Additional Comments From josh@eazel.com 2001-01-22 17:53:14 ----

Marking verified.

Josh



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:46 -------