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 98548 - Default filename search constraint should be by substring.
Default filename search constraint should be by substring.
Status: VERIFIED FIXED
Product: gnome-utils
Classification: Deprecated
Component: gsearchtool
2.1.x
Other Linux
: Low enhancement
: GNOME2.x
Assigned To: gnome-utils Maintainers
gnome-utils Maintainers
: 104799 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-11-15 01:01 UTC by Fernando Herrera
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
A patch to change the default filename search to be by substring . (1.52 KB, patch)
2003-01-03 07:12 UTC, Dennis Cranston
none Details | Review

Description Fernando Herrera 2002-11-15 01:01:56 UTC
When current gnome-search-tool you need to specify the full file name
to search it or use *pattern*
        So if I want to look for a Tom Waits song called November you need
to enter:
        *November*
        This is ok for me, because I'm an experienced user and I now what
is a wildcard, but not for a normal desktop user.
 
        Also, looking for patterns should be the default beahaviour,
because if you use a search, is because you don't know the path or the full
name. We can solve this in two differents ways:
 
        a) Internally add always a '*' before and after the pattern
        b) Use a checkbox (checked by default) to add these '*'
 
        Both solutions hide the "*" thing to the user
Comment 1 Dennis Cranston 2002-11-15 04:37:22 UTC
This will have to wait GNOME 2.2 is released.
Comment 2 Dennis Cranston 2002-11-15 07:53:55 UTC
This will have to wait _until_ GNOME 2.2 is released.
Comment 3 David Kennedy 2002-11-21 20:53:07 UTC
past feature freeze, changing to GNOMEVER2.3
Comment 4 David Kennedy 2002-12-09 15:03:19 UTC
bug 100728 is related
Comment 5 Dave Bordoley [Not Reading Bug Mail] 2002-12-09 17:37:40 UTC
Yeah I agree with this too :) Search strings should probably always
default to case-insensitive sub-strings.
Comment 6 Dennis Cranston 2003-01-03 07:12:48 UTC
Created attachment 13326 [details] [review]
A patch to change the default filename search to be by substring .
Comment 7 Dennis Cranston 2003-01-21 05:43:43 UTC
Applied to HEAD branch.  Leaving bug report open until I update the docs.

2003-01-20  Dennis Cranston <dennis_cranston@yahoo.com>

	* gsearchtool.c:  Fix bug #98548.  Default filename search 
	should be by substring.  As a result, the 'file is named' 
	entry has been renamed to 'Name contains'.
Comment 8 Dennis Cranston 2003-01-21 06:35:47 UTC
Docs updated.

2003-01-20  Dennis Cranston <dennis_cranston@yahoo.com>

	* help/C/gnome-search-tool.xml,
	* help/C/figures/gnome-search-tool_window.png:
	Updated the docs and screenshot for bugs #98548 and #100728.
Comment 9 Dennis Cranston 2003-01-30 17:11:17 UTC
*** Bug 104799 has been marked as a duplicate of this bug. ***
Comment 10 Dennis Cranston 2003-01-30 17:11:43 UTC
*** Bug 104799 has been marked as a duplicate of this bug. ***
Comment 11 Egle K. 2003-01-30 17:31:26 UTC
If this bug is fixed, then new stable version of gnome-utils should
contain fixed gnome-search-tool.

Simple users don't understand how to search with curent version :(

Now gnome-search-tool is useless for most users and this fix must be
included in gnome-utils ASAP.
Comment 12 Dennis Cranston 2003-02-24 17:23:56 UTC
The fix includes string and documentation changes.  For the GNOME-2-2
branch, the strings are frozen.  This is why the fix was only applied
to the HEAD branch.

>Now gnome-search-tool is useless for most users and this fix must be
>included in gnome-utils ASAP.

Now?  Version 2.2 uses the same logic as version 1.4 and 2.0. 


        
Comment 13 John Fleck 2003-02-24 18:47:21 UTC
I'm with Dennis. I like the changes, but rushing it into a 2.2.x
release is inappropriate.