Comment 8 for bug 509389

2010/1/24, Karol Będkowski <email address hidden>:
> Patch for filter using relevance.score attached
>
> Karol
>
> ** Attachment added:
> "0001-ui.preferences-using-relevance.score-to-filter-plugi.patch"

Thanks.

All strings returned from PyGTK are always `str` that are
UTF-8-encoded. Kupfer tries to always work with unicode internally. As
you can see, relevance.score raises an exception if one of the
arguments is a `str' and one is a `unicode'; we must pass both
unicode. (Due to Python 2.x's failings, you only get the exception if
you actually use some non-ascii character!) The plugin names and
descriptions are always unicode.

This is actually subtly wrong:
name_filter = self.entry_plugins_filter.get_text().lower()

.lower() only works correctly on unicode objects!

We can be overly clear with this:

s_name_filter = self.entry_plugins_filter.get_text()
us_name_filter = kupferstring.tounicode(s_name_filter).lower()

How nice it would be if we had a consistent style like this in all of
Kupfer, to keep track of the str/unicode problem. (s for byte string /
us for unicode string).

Also, the first argument to relevance.score doesn't need .lower(),
this is done automatically. The query string does though (this is
documented in the docstring).

I might have been wrong about the scoring: being so generous with
description ranking is confusing actually. The first ranking was
really good.. a relevance 0f >= 0.90 is equivalent to the substring
testing; we could use score > 0 for name and > 0.9 for description?
What do you think? I'm making it too complicated?

Please combine everything into one patch.

Ulrik