jmr wrote:
Thanks Brock, much appreciate the feedback. See comments below:
New webrev with your, Padraig's and Shawn's changes:
http://cr.opensolaris.org/~jmr/pm_8324_local_search_using_api_26Jun_5pm/
JR
[snip]
As a bigger question, why are we tracking and reporting the search
time to the user? From a UI perspective, I'm not sure why a user
would care whether search took 7 seconds or 9 seconds. Is there a
reason a user would want this info or is it more a
debugging/development tool for you?
Well in Google the search time is reported in brackets at the top of
the page, but its just a nice to have. At present I wanted it there to
help with the debugging and optimization work for Search. Happy to
change it or take it out given feedback from users.
Seems reasonable.
I'm slightly confused about what the "current_not_show_repos"
variable means. On lines 807-810 it seems like those are exactly the
ones you're showing the user as having errors. Also, when does the
variable get cleared? If, and here I'm just guessing, it's a list of
repos not to search, does one failed search mean you won't retry that
publisher again until the next time packagemanger is restarted?
I agree "current_not_show_repos" is misleading, renamed to
"current_repos_with_search_errors", which captures the intent here. It
was being unset in a number of places redundantly, it is now just
unset at the start of __parse_api_search_error() where it is populated
and then used in __handle_api_search_error.
When errors occur searching a repo the user is notified by a dialog
and a yellow warning triangle in the status bar:
__do_api_search
:
except api_errors.ProblematicSearchServers, ex:
self.__parse_api_search_error(ex)
gobject.idle_add(self.w_progress_dialog.hide)
gobject.idle_add(self.__handle_api_search_error)
The user can elect to not have these errors reported again in the
popup dialog. These repos to ignore on error are stored and are
persistent across invocations of PM. It does not mean that you won't
try and search these repos, only that the user won't be bugged with
errors telling them there are problems with it. What happens in this
case is that a yellow triangle is all they see in the statusbar if
there are errors on a given repo they have chosen to ignore. Clicking
on the triangle brings up the dialog listing all the repos with errors
and unsets the ignore state of these repos.
Ah, ok that helps clear things up for me. Thanks.
[snip]
1736: Why do case sensitive search by default? At least for command
line search, all the feedback we've gotten suggests that case
insensitive should be the default. Typically, if someone wants to
search for openoffice, they don't want to have to remember the exact
capitalization pattern used.
I thought that's what we were doing:
[api.Query(" ".join(pargs), False, True, None,
None)], servers=servers
query_p.Query.__init__(self, text, case_sensitive, return_type,
num_to_return, start_point)
Searching for OFFice and office turn up 26 hits in opensolaris.org
Bah, apparently counting to two was causing me difficulties yesterday ;)
1740-1750 or so: I realize this hasn't changed in this fix,
I'm a bit confused about the approach taken here. Why create an
artificial limit on the number of results generated, why not treat
this as a generator and have it throw results to the user as soon as
they're ready? When we switched to that model on the cli, the user
experience was vastly improved because results started appearing much
sooner. Also, if you're going to limit the number of results shown to
the user to be 100, why not tell the servers not to return more than
100 results?
Good point - I like the idea of getting the results back
incrementally. I have submitted this as an RFE and will work on it
after this wad goes back.
9710 PM search should return results incrementally
Great.
[snip]
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
