Total Commander

2MVV

But TC has DLL interface for quick search feature

I don't think that was necessary. The point is that you can only use one at once. Ghisler should have built-in the functionality of QuickSearch Extended.

I think TC can't use quick MFT search by default because of lack of rights - you need elevation to use such thing but it's not right to use elevated TC always.
And, not all people need this - so if it will be in separate DLL, it will be optional (won't take space if user don't need this).
Supporting of DLL that will give to TC filenames for search request is easy to integrate and light-weight solution - DLL may be written by any other people independently. Everything is small and pretty tool but it have ~550k of data and code (excluding resources) - using DLL we may reuse already written (and working) code and not to write own code for same stuff.

Well all modern operation systems today have a desktop search which means results are displayed within seconds. I don't see why anyone could say: "Damn it's too fast. It should take longer".

Lefteous wrote:Well all modern operation systems today have a desktop search which means results are displayed within seconds. I don't see why anyone could say: "Damn it's too fast. It should take longer".

I do. Because I don't trust periodically created databases and don't want indexing in real time.

I do. Because I don't trust periodically created databases and don't want indexing in real time.

That's not the point - it was just about speed not about the way it's achieved.

Well, I'm don't using indexing and system search too. But TC may have default search DLL that will use system indexed search for retrieving search results - there is no need to write own search tool.

I'm not sure if the system search engine should be reused. TC has its own system for content fields. It would be strange to mix two systems.

What content fields do you mean? And how they are related to search subsystem?

2MVV

What content fields do you mean?

All fields provided by either TC or a content plugin.

And how they are related to search subsystem?

The Windows search system is connected to the properties system which is comparable with TCs content plugin system.

Lefteous wrote:I'm not sure if the system search engine should be reused. TC has its own system for content fields. It would be strange to mix two systems.

It would be strange not to mix them. There's too much value in the TC system to throw it away for users wanting speed. Also, then the tool would have to make own dialog. It's all quite a lot of totally unnecessary work.

2m^2
Well there has to be TCs own system anyway as the Windows search doesn't work on all OSs and it's discussable if it does its job as required.

Lefteous wrote:The Windows search system is connected to the properties system which is comparable with TCs content plugin system.

I don't see any mess in using of system search and TC content fields - they are completely independent things! BTW, system properties are TC content plugin fields too:) But we are talking about file search but not about file properties or content fields. We need just to find files - all other we don't touch here.

Lefteous wrote:Windows search doesn't work on all OSs

You mean Windows 9x? They don't have MFT files so fast search is unavailable anyway (but maybe only search in indexed locations but it is a bad way). Anyway again, if system search doesn't work, user just won't use it and will use regular search!

I am starting to support the search plugin idea. This way my big wish of an indexed search where one could define which WDX values to index could be realized.

Roman

I don't see any mess in using of system search and TC content fields - they are completely independent things!

One of TC's design princriples has always been to take only what is absolutely necessary from Windows. I don't think TC should rely on Windows search.

system properties are TC content plugin fields too

No - I'm talking about the Windows property system introduced in Vista.

But we are talking about file search but not about file properties or content fields. We need just to find files - all other we don't touch here.

Of course it's about finding files but not just by name. Files can be found by their content or metadata or attributes and so on.

You mean Windows 9x?

Windows XP without installed Windows search and below.

Anyway again, if system search doesn't work, user just won't use it and will use regular search!

So better introduce something that works fine.

2Hacker

I am sstarting to support the search plugin idea. This way my big wish of an indexed search where one could define which WDX values to index could be realized.

It don't see why an external library could do the job better than an internal solution.

I really wonder why such technical details are discussed prior to the required functionality.

Lefteous,

It don't see why an external library could do the job better than an internal solution.

Well, the external library would exist, as opposed to an internal solution. In other words, I believe implementing a search plugin interface would be faster to implement than my idea of indexed search in TC directly. I am not saying I would be against an internal implementation, of course.

Roman