Live data from Hacker News

Jarvis, an Alfred Alternative for Windows

github.com

31–40 of 56 posts

Re: Jarvis, an Alfred Alternative for Windows

#31

I always had a fondness for Gnome DO, which I believe predates Alfred by a few years. https://do.cooperteam.net/ Does anyone know the original text based launcher? Quicksilver perhaps?

I think Quicksilver is the one that started the trend that has persisted for the last 16 years or so — and that trend certainly increased with Spotlight’s introduction with Mac OS X 10.4 Tiger in 2005 — although as mentioned below, LaunchBar predates it by 6 or 7 years. But Quicksilver really introduced (as far as I remember) the UI that most other modern launchers still use, and that Spotlight later “stole” — which…

Yep, I was a big QS fan back in the day but switched to Alfred for its cleaner look and stayed for its crazy speed and stability.

Re: Jarvis, an Alfred Alternative for Windows

#33
I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description.

The truth is too its actually really easy to access programmatically.

Instead of them rolling their own indexer, they should use something like elastic which has an on par number of providers for various file types.

Re: Jarvis, an Alfred Alternative for Windows

#35
post #33

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description. The truth is too its actually really easy to access programmatically. Instead of them rolling their own indexer, they should use somethi…

If the backend of Windows Search is amazing, why is the front-end user experience abysmal? The problems just don't seem like front end problems: the search is occasionally slow, it doesn't even reliably find installed programs by their name, and if the result pops up while your next keystroke is underway it will sometimes lose the result even if that keystroke is correct, and somehow finding the result again will require removing more than the single correct keystroke that made your desired result disappear. The mind boggles.

I'm not familiar with Windows internals, so I should clarify: I'm talking about the search functionality invoked by typing after pressing the Windows key.

If I were an app developer in this space I would not trust my core functionality to anything even remotely associated with the above, and I strongly suspect that the complexity of handling the long tail of functionality you mentioned has something to do with why the windows-key search experience sucks. Certainly the fundamental task is not intractable because Spotlight (Apple's search) has been Good Enough for a while. IIRC it became tolerable around the time SSDs became standard. Windows-key search isn't quite there yet. Until it is, I'll take good execution on the basic 80% of functionality any day.

Re: Jarvis, an Alfred Alternative for Windows

#36
post #33

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description. The truth is too its actually really easy to access programmatically. Instead of them rolling their own indexer, they should use somethi…

Wait, by Elastic, do you mean Elasticsearch? Genuinely curious, as I've only ever used it for large scale log ingestion/APM etc. in our production clusters, but what's the overhead on a single user machine?

Re: Jarvis, an Alfred Alternative for Windows

#37
post #33

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description. The truth is too its actually really easy to access programmatically. Instead of them rolling their own indexer, they should use somethi…

If the backend of Windows Search is amazing, why is the front-end user experience abysmal? The problems just don't seem like front end problems: the search is occasionally slow, it doesn't even reliably find installed programs by their name, and if the result pops up while your next keystroke is underway it will sometimes lose the result even if that keystroke is correct, and somehow finding the result again will req…

The front end is a mystery to me, windows search backend is a queryable system, it's reliable, impressively fast, and suffers from none of the issues that have plagued not only the win10 search, but windows explorer as well.

I've never understood why it's performance has been deemed acceptable.

I'm on my phone right now so forgive the random sample, but this gives the gist of its usage. https://stackoverflow.com/a/34340288

The only issue I have seen is when the index corrupts, this was more common in win7, and in our research it was often the result from an over aggressive AV jamming up the process.

But I've written a number of systems that make use of this, and when comparing other ways to accomplish this sort of in depth search, it's the most reliable and manageable.

It does have the caveat that it works best on places indexed by the OS, and adding locations to the indexer via code requires some pinvoke stuff most people aren't comfortable with.

Re: Jarvis, an Alfred Alternative for Windows

#38
post #33

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description. The truth is too its actually really easy to access programmatically. Instead of them rolling their own indexer, they should use somethi…

Wait, by Elastic, do you mean Elasticsearch? Genuinely curious, as I've only ever used it for large scale log ingestion/APM etc. in our production clusters, but what's the overhead on a single user machine?

I do mean elastic search, and the hardest part is automating the installer, integrating the providers for all the file types you want, and building the first index,in a passive manor.

But once you do that the overhead isnt horrible, you do the indexing on change, and results comeback as fast as a typical small query, 10 seconds tops on a typical desktop machine.

We wrote a scheduler that on windows monitored the windows indexer itself, when it kicked off we scheduled it, and trigged it once the system finished.

I don't honestly recommend it over windows search, but if portability, and multi system searching is required it worked great.

But not a task for those who are crunched for time, or lack resolve.

Post reply on HN