Application Menu Indicator

lp:~desrt/indicator-appmenu/hud-performance

Created by Allison Karlitskaya and last modified
Get this branch:
bzr branch lp:~desrt/indicator-appmenu/hud-performance
Only Allison Karlitskaya can upload to this branch. If you are Allison Karlitskaya please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Allison Karlitskaya
Project:
Application Menu Indicator
Status:
Merged

Recent revisions

213. By Allison Karlitskaya

HudWindowSource: fix a couple of leaks

 - don't leak icon name while changing windows (fixes lp:972354)

 - don't leak the collector on finalize (which never happens)

212. By Allison Karlitskaya

Adjustments for Ted's review comments.

211. By Allison Karlitskaya

Increase the default swap penalty to 15

The current value is too low. It allows "xyze" as a valid match for "File" (3
swapped characters at a cost of 10 each gives a total cost of 30, which is the
maximum permitted value).

It also causes an issue with accents. Consider the case of typing
"pref" and encountering the menu items "préférence" and "précédent".
Clearly the user wants "préférence". During normalisation, we convert
each of these strings to "pre'fe'rence" and "pre'ce'dent".

"pref" vs "pre'fe'rence" is best scored as the first "'" being dropped
and the trailing "e'rence" also being dropped. 10 points for the accent
drop plus 7 for the trailing "e'rence". Total of 17 points.

"pref" vs "pre'ce'dent" seems like it should be scored worse since the
accent is dropped and the following character is incorrect. Instead,
however, the algorithm assigns a lower score for the possibility that
the accent is replaced by the letter "f" (10 points) and then the rest
of the characters "ce'dent" are dropped (7 points). Also a total of 17
points.

This tie would be prevented with a higher swap cost.

This problem could be fixed by special-casing the dropping of accents in
the core search algorithm and I tested this approach but it had a
substantial performance cost on the rather tight inner loop (nearly
doubling the amount of time to do a search).

Another possibility would be to drop all accents entirely during the
normalisation process. This sounds acceptable for French, but I imagine
other languages may find this to be less than ideal.

Also, consider "fl" against "file" and "fix" as another example that
doesn't rely on accents to make its case (although the argument is
somewhat weaker here). This shows that we should probably just increase
the swap cost.

210. By Allison Karlitskaya

hud-performance: increase the size of the test again

The testcase size was reduced for easier valgrinding. That accidentally
got committed with a fix for a leak that was found while valgrinding.
Put it back to the larger value.

209. By Allison Karlitskaya

'make distcheck' fixes

 - fix srcdir != builddir issue for new testcase
 - make sure the new gsettings schemas get disted

208. By Allison Karlitskaya

fix small leak in testcase

207. By Allison Karlitskaya

really. don't delete schemas on 'make clean'.

206. By Allison Karlitskaya

Skip checking of search terms when it's not possible to take the term

There are two situations in which a term will never be taken:

 - the max cost has already been exceeded

 - the cost of taking the term can't possibly beat the cost of dropping it

In those two cases, don't do the extra work.

205. By Allison Karlitskaya

Add a good search performance test

204. By Allison Karlitskaya

test that the new distance algorithm fixes bug 947283

The new needle/haystack matching algorithm penalises trailing haystack
terms that are not matched to needles. Result: "save" now matches "File
> Save" better than it matches "File > Save As...".

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:indicator-appmenu/0.4
This branch contains Public information 
Everyone can see this information.