My opinion: the last thing you want is a complicated, 'bureaucratic' syntax like Windows Search has. It makes it effectively unusable without it's manual at hand. Read further how that could be avoided (again: my opinion)
I'm thinking about having two functions for searching content:
1) a simple one and
2) a specific method one, for example:
width: would search any image or video for the specified width, while pngwidth: or jpgwidth: or mkvwidth: would search using the specific method for searching for width. Similarly, content: could use IFilter, UTF-8 content, UTF-16, ansi content and any other text content it could try..
*.png pngwidth: would be faster than *.png width: as it wouldn't need to check png files for a jpeg header, or mkv header etc... (this is how it currently works for Everything 1.3)
I can make the optimization where Everything can attempt to read the png header first when a filename with .png was specified.. as a png file without a png header is not going to occur often.
While Everything is rather relaxed to search syntax, Everything does have a lot of search functions. I'm not sure at this stage if I should avoid adding search functions just to keep the list small. I think this will come down to how the help is presented, perhaps separate list of common functions names and a complete list, as most users will not care for pngwidth:, but might find width: useful.
When content indexing is implemented, I will consider an option so you don't need to specify content: or width: etc.. , simply typing in 1920 will show all images with a width of 1920. Maybe a list of check boxes so Everything can automatically search content without the specific search function.
Same could be applied with size: and date modified information..
This takes away a lot of control from the user, I would rather have the user type in size:14kb rather than just 14kb because that could be misrepresented. I will still give them the option to automatically search size:<search> width:<search> etc, however it would be disabled by default and would only work for content that is indexed.
What is high quality of Preview? I would say similar to WIndows Preview but with the content search query highlighted in Preview.
That's a very nice idea! Will involve a lot of extra code in Everything I guess, as this is now largely 'outsourced' to Windows itself (and Windows' preview host (prevhost.exe) doesn't have that feature)
A good place to start would be to show a "quick preview" that is a text only preview with content: searches matches highlighted.
I'll consider adding something like this..
void wrote:IFilters do not search file meta data.
Isn't that what the iFilter::GetValue() is all about?
IFilter::GetValue gets the type of the text, such as is the text a date or currency or simple text etc..
It is more or less a hint for how to store the actual data when content indexing.
While an IFilter implementation could be used for reading meta data, it is mostly used to read the plain text of documents, such as Word or PDF files.
What are your thoughts on content: searching / id3 searching / meta data searching?
Don't know if this was aimed at @Stamimail or in general, but my opinion:
I'm happy to hear anyone's input on the subject.
My current thoughts are to make content: "smart" and attempt to understand the content, and have other content functions for very specific methods.
1. Everything should let the user to create and combine custom "Content Searching" like:
content1: <== utf8content:+ansicontent:
content2: <== utf8content:+ansicontent:+utf16becontent:
content3: <== utf8content:+utf16becontent:
I'll look into making content: not fall back to UTF-8 and make it "smart" by attempting to understand the content, this might involve searching for UTF-8, UTF-16, ansi and other codepages. However, this is only relevant for unknown file types, ie: the file does not have an IFilter association.
The question is, is using just the IFilter enough?
Like you say, perhaps present to the user a list of content types, and allow them to check them as needed. If it can be avoided, and the user can search all content types with content:, that would be the preferred option.
2. I think the main and the real problem is the Preview stage.
I think users simply will look for alternative to Everything to get the high quality of Preview they are looking for.
I don't think is the job of Everything to make those "iFIlters", especially since Everything has a lot to do on the TODO list. Leave it to v1.6...
I do have "Implement my own text preview handler" on my TODO list, I will look at rendering and highlighting Word and PDF and other files via IFilter in plain text. This would have to be a separate "Preview" pane, one for formatted text and another for plain text.
IFilters do not return any formatting, so Everything would have to implementing its own Word / PDF renderer, not something I'm looking to do anytime soon.
Previewing and highlighting plain text might be a good start..