Red Hat Bugzilla – Bug 468156
Can't search for partial matches in word
Last modified: 2009-01-14 08:46:10 EST
Description of problem: Can't search for partial matches and no support for wild-cards. E.g. searching for the string "avant window navigator" or "avant" or "avant*" shows nothing. Searching for the string "avant-window-navigator" though, works. This is very unintuitive and quite useless to an end-user - no end-user should be expected to remember the names of every package in the Fedora repository. Wild card searches, searches for partial matches and category searches (e.g. searching for "dock" should show all dock implementations available in the repository) are absolutely essential. Version-Release number of selected component (if applicable): Fedora 9 desktop updated as of now. How reproducible: Always Steps to Reproduce: 1.Go to Administration/Add Remove Programs 2.Search for "avant" (without quotes) 3.Observe that nothing is found. Actual results: Nothing is found! Expected results: Should have found the Avant Window Navigator (core and applets) packages. Additional info:
Searching for avant returns me three packages. PackageKit deliberatly doesn't try to do wildcard searches, as most people don't expect to use them to search like that. Do you have autocompletion turned on? With autocompletion I get all the package results from searching for "ava-......................" and then they all pop up. If you change the search type to a group search, then you'll get a match against the summary and description text, which is probably what you want.
Ok, perhaps I have the wrong configuration - but from the UI (gpk-application v0.2.5) it is not clear how to set preferences. The following menu-tree is available: - System |_ Software Sources |_ Refresh Package Lists -Filters |_ Installed | |_ Only Installed | |_ Only Available | |_ No Filter (ENABLED) |_ Development | |_ Only Development | |_ Only End-user | |_ No Filter (ENABLED) |_ Graphical | |_ Only Graphical | |_ Only Text | |_ No Filter (ENABLED) |_ Free | |_ Only Free | |_ Only Non-Free | |_ No Filter (ENABLED) |_ Hide sub-packages (DISABLED) |_ Only Newest Packages (ENABLED) - Help |_ Help |_ About The "Find" Text-Control has an icon which allows toggling between 3 types of searches: 1. Search By Name 2. Search By Description 3. Search by File Name Selecting (2) gives me 3 results (the 3 I'm interested in). However this isn't very clear, nor is it described in the documentation. My personal opinion is the default should be (2), as an end-user can not be expected to know exact package names - e.g. even in the simple case of Avant Win Nav, the package names are inconsistent: a. the core-package is named "avant-window-navigator" b. the applets are in a package called "awn-extras-applets". Since this type of naming inconsistency is bound to occur - perhaps because add-ons are contributed by third parties and assimilated by the Fedora maintainer, or some other reason - searching by description is probably more suitable as a default. In which case, this probably reduces to a usability/documentation issue and not a bug per-se.
Note - I haven't been able to find out how to enable auto-completion. This is probably just me - I'm sure most other users already know how to do this. Also, when you say "group search" I assume you mean selecting one of the many groups available on the left panel of the application. I don't use this as I don't really know (apart from fairly obvious packages like Open-Office, Gnome etc.) where/how packages are categorized. If not, could you explain what you mean by doing a group search? I'm sorry if I come across as a bit dense, but this is the reason I use GNOME - I am dense and would rather concentrate on getting things done (being dense, I am quite slow already just doing the things I should be doing!) than twiddling preference knobs :)
"""PackageKit deliberatly doesn't try to do wildcard searches, as most people don't expect to use them to search like that.""" I don't see the conflict, for "name search", if someone doesn't expect wildcard searching then they won't input * or ? ... however it's possible it'll be confusing to allow yum* in a "name search" (really a list operation) ... but not in the other searches (really searches). IMNSHO the default for gpk-application should be the same as for "yum search", providing similar output (ie. try "yum search avant window navigator" vs. what PK can produce). However I'm not sure how long it'll take to get that level of search. If we could move to "search on name, summary, decription or url" that is an ok first step. Given the current choices then "name only" is probably better than "summary only" or "description only".
[QUOTE] IMNSHO the default for gpk-application should be the same as for "yum search", providing similar output (ie. try "yum search avant window navigator" vs. what PK can produce). [/QUOTE] As per the YUM man-page: [QUOTE] search Is used to find any packages matching a string in the description, summary, packager and package name fields of an rpm. Useful for finding a package you do not know by name but know by some word related to it. [/QUOTE] the default for the CLI already seems to be to search in the way users like me would expect it to work - i.e. search for packages the user doesn't know the name of! Obviously, the PK GUI doesn't work like this. Having completely exclusive searches (name only OR description only OR summary only) seems a bit of a (self-imposed?) implementation handicap that makes for a less than ideal GUI.
commit df09494916e547555a11a976da24e016ea3c8da4 Author: Richard Hughes <richard@hughsie.com> Date: Sun Dec 21 15:45:14 2008 +0000 feature: set the default search mode to details (not name) and preserve the search type in GConf if changed in the UI :100644 100644 8c5591b... 6a73ab7... M data/gnome-packagekit.schemas.in :100644 100644 5ef31a8... 97d2e77... M src/gpk-application.c :100644 100644 c454c99... c74b7b7... M src/gpk-common.h