doesn't always list the closest matching first
Bug #930065 reported by
Sebastien Bacher
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Application Menu Indicator |
Fix Released
|
Medium
|
Ted Gould | ||
indicator-appmenu (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Using current precise (i.e 0.3.90-0ubuntu1) with gedit in french:
- I type "pré" in the hud to go to "préférences"
- the choises that are listed are:
* Fichier > aperçu avant impression
* Connexion au réseau...
* Edition > préférences
I think the third one should be listed first since it does exact match what I'm typing where the others don't
Related branches
lp:~ted/indicator-appmenu/lp930065
(Merged)
lp:~indicator-applet-developers/ubuntu/precise/indicator-appmenu/upstream
- Ken VanDine: Pending requested
-
Diff: 1560 lines (+613/-245)32 files modifiedChangeLog (+255/-0)
Makefile.am (+1/-35)
Makefile.am.coverage (+48/-0)
Makefile.in (+45/-39)
configure (+106/-68)
configure.ac (+4/-1)
data/Makefile.in (+5/-11)
debian/changelog (+19/-1)
debian/control (+4/-0)
docs/devel/html/HudAppMenuRegistrar.html (+1/-1)
docs/devel/html/HudDbusmenuCollector.html (+3/-3)
docs/devel/html/HudResult.html (+4/-4)
docs/devel/html/HudSource.html (+7/-7)
docs/devel/html/ch01.html (+1/-1)
docs/devel/html/ch02.html (+1/-1)
docs/devel/html/ch03.html (+1/-1)
docs/devel/html/ch04.html (+1/-1)
docs/devel/html/ch05.html (+1/-1)
docs/devel/html/hud-HudSettings.html (+2/-20)
docs/man/hud-cli.1 (+2/-2)
docs/man/hud-dump-application.1 (+2/-2)
docs/man/hud-list-applications.1 (+2/-2)
docs/man/hud-verify-app-info.1 (+2/-2)
m4/gcov.m4 (+13/-10)
src/Makefile.in (+18/-18)
src/hudquery.c (+1/-1)
src/hudtoken.c (+6/-0)
src/hudtoken.h (+1/-0)
src/indicator-appmenu.c (+2/-0)
tests/Makefile.in (+53/-11)
tests/test-dbus-message-count.in (+1/-1)
tools-vala/hud-gtk.c (+1/-1)
tags: | added: hud |
Changed in indicator-appmenu (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in indicator-appmenu: | |
status: | Confirmed → In Progress |
assignee: | nobody → Ted Gould (ted) |
milestone: | none → 0.3.91 |
Changed in indicator-appmenu: | |
status: | In Progress → Fix Committed |
Changed in indicator-appmenu: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I had a comment about search quality when reviewing part of the hud code[1]. Will paste it here again so that it doesn't get lost:
imo, sorting by summing the relative usage and distance isn't a very good
strategy, as both usages and distances will tend to only have few very
small and many very large values, which is always tricky when dealing
with percentages.
Somewhat exaggerated example: Usage count for "open" and "save" is 10 each.
I type "blur" (which is a perfect match) for the first time:
distance usage total (as in usage_sort())
blur 0 0 % 0 0 % 100 %
open 4 50 % 10 50 % 100 %
save 4 50 % 10 50 % 100 %
Ranking those 3 the same is surely not what we want?
[1] https:/ /code.launchpad .net/~ted/ indicator- appmenu/ hud/+merge/ 89905/comments/ 194449