0

Hi.

I believe this is simple and will make a difference.

Once upon a time, I created an application for Windows, called "Key Launch". It was very similar to the application launcher (the bottom-left button on the taskbar) or KRunner (Alt+F2).

It was maaany years ago, and this project (Key Launch) is now dead. It's been dead since many many years actually.

This utility allowed users to enter a few characters to run an application. It was quite popular in the Windows XP era, and it slowly died when Windows 7 came in (it has a similar functionality built in, although my app in my opinion was much better:) )

Well, what this app could do, and KDE's app launcher/krunner can't (as far as I know) is this:

Let's assume there are three apps available on the system, used to edit text files, "super editor", "edit plus" and "blah". The last one has an "edit" word in its "description".

1. When user entered "edit" (without quotes) all these apps were listed, with the "blah" at the very end (at first. See the #cool_thing point below).

2. User could enter words in any order, like "editor super" - it still worked just fine. He/she could also enter e.g. "ed sup"

3. User could make typos - like "edytor" - still those apps were listed, although if there was indeed an app/doc called "edytor" - this one was listed first (again, at first. See the #cool_thing below). I think I used levenshtein algo (really, I don't remember, it was veeery long time ago)

4. Yes, this app could do math calculations and a few other things.

And now, the #cool_thing:

This app was able to LEARN. I.e. if user entered "edit" and then run the "blah" app say 3 times, the very next time, this app ("blah") was listed first. So it was enough to start the app (ctrl+space) -> enter "edit" -> hit enter to start the "blah" app.

It was constantly learning, so if user changed his mind, and started preferring "another app to edit files" when they entered "edit" - after a few tries the app learned it.

A few other points:

User could create aliases, like "e" = "run the 'blah' app" - he/she didn't have to wait until Key Launch will learn that. Plus, aliases had always the highest priority.

User could drag & drop apps/docs to the Key Launch program - the app then proposed creating an alias for that file.

User could add more directories to "scan" - i.e. by default only "start menu" and "documents" were indexed, but we could add more directories.

Key Launch indexed the stuff on reboot, and kept it in RAM to make things faster. It wasn't like it was reading the directories every time user started entering characters. It watched for changes in directory it was supposed to scan. For me KDE's solutions are a bit slow, is that because it reads directories every time we want something? BTW: reading icons was done in separate thread in Key Launch. Really, it was just a matter of a second to open an app/doc I want.

The order of result list was based on factors, like: position of app = (levenshtein result * 0.3) + (how_many_times_user_entered_that_characters_and_started_this_app * 0.5 + the_app_starts_with_the_characters_entered_by_user * 0.1 ) etc etc... There were more factors I don't remember now.

Really - this wasn't very complicated to implement, and the result was that the app *knew* what I want in 99% of cases.

When I now use the kde's app launcher - I'm a bit disappointed. It isn't very wise, IMHO more "intelligence" given to that widget would be very cool.

p.s. Probably some of the things my app could do are already implemented in app launcher/KRunner - but somehow I can't see it.

Summary: my "Key Launch" was much faster, the results were much more accurate, the the entire algorithm responsible for the order of results had only ~100 lines of code. Not too much for this kind of "smartness".

Can you put a link to source code of your application?

@Lachu - thanks for your interest. It was really a looong time ago, I wasn't very much interested in Open Source movement back then. But yes, I will look into my backups/museum/ and I'll try to find it Although this was a time a was a beginner in development, plus, it was very Windows - glued ( sorry for my English). I'll try to find this very code responsible for getting the best matches.

Thanks again for your interest!

edit: : Oh, no, that won't work. I've just looked at the code - there is a lot of my own utils functions in use, my own array implementation , my own levenshtein-like function, plus it's multithreaded - not only apps' icons are being read in a separate thread, but also .lnk files (links to other files in Windows OS), and dirs in general as soon as the app thinks it is necessary to re-scan the dirs. In short - it is a bit more that 100 lines of code, and there is no central place where I do the math. I wasn't thinking about open sourcing this, e.g. comments are in my language (not English) and generally, it's a big mess (coded in a "nobody will see it" way) . So, no, my code is not useful in this case.