Dash - Add sub-string matching to Dash search

Needs design discussion. Marking incomplete in the meantime.

I fully agree with you. In gnome-do, I just have to type "f" and press "enter" to open firefox. With unity, I have to type "f" "i" "r" "e" then press tab twice and finally press enter to open firefox. It would be much more efficient if there was an auto-completion or suggestion 'à la' gnome-do.

ur report is incomplete so complete it use this code in terminal
apport-collect 752259

apport information

apport information

OK, done. But I'm not sure that it will be that helpful for this issue, as it isn't a problem with the operation of the software. It's a design issue.

Btw, there is also an entry on this topic in the ubuntu brainstorm (idea 27530).

Well, it'll be even better if we could get many of the features that made Do more than a launcher, like executing actions over items and integrating with web services and stuff. It's quite terrific because a regular user can keep using it as a launcher, but a power user could work wonders with it by knowing the key bindings and advanced features.

Just out of interest, what is the "Fix Released" referring to? Has Unity been modified to have the above functionality? Awesome!

seanlano, no, Ayatana Design uses statuses differently from every other Launchpad project. Fix Released means that the design is finalized. To see whether it's implemented, check the status in the project where the bug actually exists (in this case, Unity).

@mpt: ehm, but what's the design decision here? I can't find any implementation details...

Let me chime in here, as apps lens maintainer who did this original behavior, although I don't make calls for design.

The current behavior is very much intentional for many reasons.

 1) I am quite sure that 99.9% of the non-geeks in my social circles would be utterly confused about the perceived random matching (which I admit, i was myself for several months with Do)

 2) I believe it is important that we have the same matching for installed apps as we do for those we find in the Software Center catalog (in Apps Availabale for Download). And in fact, also the same mathcing criteria for files. Doing sub-pattern matching like described on massive corpora like the S-C catalog or the entire files index is not feasible, nor would it provide sensible results.

 3) I don't buy the argument that it is easier to type "sp" than it is to type "syn". That's a matter of muscle memory. And isn't it even easier to hit <super>-N where N is the offset of the launcher item?

 4) Experts can easily uninstall the default apps lens an install a custom apps lens that has the desired behavior (given that some writes it first of course ;-))

My suspicion is that an element of the "random results" is because the result is evaluated at the point '[enter]' it hit, rather than computing the result for the whole line of input, then selecting the top result. (eg. typing slowly, or typing fast produces different == non-predictable results).

Marco, I have no idea, sorry. The Dash specification doesn't mention how applications (or items in general) should be chosen as results.

As a note - I hacked together a "playground" we can use more easily to play around with different matching semantics in lp:unity-lens-bliss. See also http://www.grillbar.org/wordpress/?p=568

i hope that the camel-case match in the dash will comes with the next unity release.

In 12.04 I've noticed that dash returns searches for substring (partial words) for files and folders but not for applications. E.g.:
 - searching for "hrom" returns "Chromatic Fantasy" file but NOT "Chromium Browser"
 - searching for "chrom" returns both file and application
It would be very helpful to return the partial word matches for applications also.

I 've tested in 13.04 the scenario, and there it is working as Adam described. So we have already partial searching, but only (or at least) for files and not for apps.

With the introduction of libcolumbus and fuzzy matching it now (13.10) works as described in this bug report (one can argue it's too tolerant and fuzzy).