ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Find And Run Robot

FARR and Indexing Option - Feedback Requested

(1/15) > >>

mouser:
As most of you know, one of the things that makes FARR different from some other launchers is that FARR does not index your hard drives, it searches them on demand.

There are advantages and disadvantages to this.  The primary advantage is minimal memory use; the primary disadvantage is slower search for documents outside of the start menu (more on the motivation for not using indices is here).

Those using FARR primarily as an application launcher are well served by this, but there are times when people would like to have the option of using an index for super fast search of complete hard drive contents.

Now there are quite a few plugins that let FARR interface with 3rd party search indexing tools such as Everything,Locate32,WindowsSearch:

* https://www.donationcoder.com/forum/index.php?topic=10501.0
* https://www.donationcoder.com/forum/index.php?topic=18724.0
* https://www.donationcoder.com/forum/index.php?topic=16582.0
* https://www.donationcoder.com/forum/index.php?topic=18016.0
I have long planned to add an indexed search option into FARR, and this last week I began writing some code to do this.. But i'm rethinking my approach.

There are actually a few ways to go with this:

* I could write my own custom indexing database code - lots of work but would be tightly integrated into FARR; could control memory vs disk usage tradeoffs.
* I could try to query ntfs master table data directory - search engines like Everything use NTFS data too but also use a database and more tricks; this would be faster than normal FARR search, but to what degree I don't know; would not require too much more memory use.
* I could try to interface with other search engines like the plugins above do; disadvantage is you need to install those and have them running; advantage is the power of these tools and the ease of coding
I started out thinking that I would like to avoid that last option, but I'm starting to think now that it would be the best approach.

So here is what I'm currently thinking.. I'm thinking that I will make some fairly minor changes to FARR, to allow plugins to more seamlessly do the job of replacing the normal file searching.

The Everything SDK is best suited for a first implementation.

So I was thinking of basically providing the same functionality as the other great Everything plugins that have already been written for FARR, except that you would be able to tell FARR to basically use the plugin to do all normal file searching, rather than having to use an explicit alias to trigger the search.

For those of you who have been wanting indexing support in FARR, what do you think of this approach?

I do think what valid question is:  If you have the Everything tool running, and just one click away, why not use that instead of FARR when you want to search for documents (as opposed to start menu items)..

mouser:
Maybe I should focus on adding whatever i need to add to farr to allow a plugin to seamlessly take over file system searching, and then let others write specific plugins for Everything, Locate, Windows Desktop Search, that will do the actual work.

Armando:
So here is what I'm currently thinking.. I'm thinking that I will make some fairly minor changes to FARR, to allow plugins to more seamlessly do the job of replacing the normal file searching.

The Everything SDK is best suited for a first implementation.
-mouser (June 22, 2011, 02:40 PM)
--- End quote ---

While I think Everything is great (it's the file name search tool I use the most), I wonder about its development. Doesn't seem too active. But then, it's probably still the best tool, all things considered (resources used, speed, etc.).


So I was thinking of basically providing the same functionality as the other great Everything plugins that have already been written for FARR, except that you would be able to tell FARR to basically use the plugin to do all normal file searching, rather than having to use an explicit alias to trigger the search.
-mouser (June 22, 2011, 02:40 PM)
--- End quote ---

I like that.^

I do think what valid question is:  If you have the Everything tool running, and just one click away, why not use that instead of FARR when you want to search for documents (as opposed to start menu items)..
-mouser (June 22, 2011, 02:40 PM)
--- End quote ---

I use both**, but  prefer to just use Farr when it's only for quick launching.

**Right now, the main reason why I'll often switch to the Everything interface is because of the wrong "diacritical marks" display : all Everything results containing accents/diacriticals aren't displayed properly in Farr. That could most probably be fixed since those are displayed correctly when I'm not using the everything plugin...
The other reason I sometimes switch to the Everything interface is to be able to sort by dates, something I wish Farr was able to do.

Maybe I should focus on adding whatever i need to add to farr to allow a plugin to seamlessly take over file system searching, and then let others write specific plugins for Everything, Locate, Windows Desktop Search, that will do the actual work.
-mouser (June 22, 2011, 03:34 PM)
--- End quote ---

I like that option too.

However, if that path is chosen, maybe one of the more mature plugins should be installed by default. New users could then experience Farr in all its greatness without having to hunt for plugins.  Maybe the "Windows Desktop Search" plugin would be the most suitable -- not my personal fav (still a bit unstable here...) but it might be the most used (installed by default in recent Windows flavours).

daddydave:
I think it's great that you plan on actually doing this, I've wished for this forever.  :Thmbsup:

Those using FARR primarily as an application launcher are well served by this, but there are times when people would like to have the option of using an index for super fast search of complete hard drive contents
-mouser (June 22, 2011, 02:40 PM)
--- End quote ---

This seems to me an odd thing to say, although I must be in the minority. I think it is the other way around. If I am searching for files (for which I currently use Locate32), I will tolerate some lag in search results, but when I am launching applications, I don't want to wait for several seconds before I can press Enter as I currently have to do in FARR.* That's the great thing about Launchy, the instant I press a letter, I get the match instantly so I can go ahead and press Enter as soon as I hit the letter if it is the right app. Launchy of course is not as powerful as FARR, but I try to run both and it is hard to get in the right groove with FARR because of this, and wondered if I can set up a somewhat Launchy-like configuration for FARR.


*This is fact is one source of irritation I have with the Windows 7 start menu, compared to using FARR and especially Launchy, is that I have to wait several seconds to make sure I am launching the desired application and not an unwanted Windows file search. FARR's delay isn't as much as the Windows 7 start menu's, though.

Josh:
This is a feature that I have been bugging, much similar to my months of personally pestering mousey on IRC for the filesystem navigation in FARR, for. Database indexing can be a very beneficial feature for FARR if done correctly. Now, for my feedback on the associated options presented by our administrator.

The option to have each search option as a plugin written by users is good but I do not feel it should be the first option for implementation. There should be a core, integrated, feature in FARR simply due to the nature of plugins. Plugins tend to be developed and once the author loses interest, go to the wayside. How many of the plugins for FARR are actively maintained? I feel that either the NTFS or home-brewed option should be the primary option for this.

Depending on the level of work, I would say do the tightly integrated method first. This option will provide the most benefits, memory-wise, and can result in a much quicker search time since FARR can index monitored folders for specific file types at every X interval. That is my first choice. NTFS is a natural choice as well due to the very nature of Windows in the modern age. FAT32 is going to the wayside, especially as drive size increases, and using the journal provides many additional benefits such as access to file properties and possible metadata which can further be used to enhance FARR.

I would like to state, again, that I feel the plugin based option should be considered LAST unless one is going to be developed and maintained by mouser. And this should only be done once the quickest engine for indexing and database searching is identified.

I, for one, cannot wait for this. Mouser will tell you just how long I have been pestering him for this. I am glad to see this feature making its way into FARR, finally.

BE SURE TO POST BETAS/ALPHAS!!! I want to test!

Navigation

[0] Message Index

[#] Next page

Go to full version