[Request] Advanced File Search additions...

[Innuendo]

Some MP3-related criteria on the Advanced tab would be wonderful.

Being able to search on bit-rates & ID tag fields would make the file search much more powerful.

DOpus does this and I find myself going back to DOpus just to use their file search.

[JackFoo]

Why the bias, lets add MPC,OGG,SPC,AC3,AAC,MP3,MP2,WMV,...,ETC why only MP3. There are so many formats, why stop here, lets add video formats as well AVI,MPV,...,ETC hmm, while we're at it how about archive info as well RAR,ZIP,7Z,RK,ARJ,LHA...,ETC.

Now on a more serious note, while I'm all for expanding TC capabilities, some things are very specific and should be left to specific programs. TC is a file manager in the general sense, it's not media library implementation nor should it be.

---> IMO

Cheers.

[djk]

TC is a file manager in the general sense, it's not media library implementation nor should it be.

Yes, you are right, but if it has become your "main" program, after some time you.. expect everything form it

[Jonas]

Support of plugins for searching would be nice.... So if Christian would implement an other plugin-interface for the search-dialog you could just add 'mp3.wsx' and seach also in ID3-tags *dream*

What are the others thinking about that?

[Innuendo]

JackFoo,

I merely stated MP3 as that is the de facto standard in audio files. Didn't mean to be biased.

I'm not wanting to turn TC into a media library...just trying to get implemented a better way to manipulate, copy, move, and find my media files....which is what a file manager is supposed to help do...whether it be a media or non-media file.

Jonas,

I think you have the perfect idea on how to solve the problem. People who want/need it, could install the plugin. Those who don't, can leave that plugin off their system.

[matis_]

Support of plugins for searching would be nice.... So if Christian would implement an other plugin-interface for the search-dialog you could just add 'mp3.wsx' and seach also in ID3-tags *dream*

What are the others thinking about that?

i think it's a great idea !

[Jonas]

I'm imagine it like this:
The user selects the plugin which he wants to be used (if none: the 'find text'-stuff is visible)
TC gets a list of all fields from the plugin with name, id and type (for the name it would be useful if the plugin would know with which language TC is running), type could be only TEXT at the beginning and may be extenable to check-, radio- or comboboxes.
And a string putted in the 'search for'-field
for 'mp3.wsx' it could be
Title, 0, TEXT
Artist, 1, TEXT
Length, 2, TEXT
'Search for'-prefix from plugin => '*.mp3'
for example.

The user extends the 'search for'-field and all the other options and then TC scans the filetree. If he has found a file according to the other searchoptions he passes this filename to the plugin. Afterwarts TC calls in this exemple three times a funtion bool FindTextField(id, const char *) and gets each time true or false. According to an AND or OR connection betewwn the fields TC decides if he puts this file in the results-list or not.
And it would be great if the plugin could use TC's RegEx-support comming with TC-6

An other possibility would be that not the plugin consider if the search is succesful or not but TC. The Plugin would in this case return the conent of the field to TC and not getting the users input and performe the search itself...

I don't know which way is the best. Both of them have pros and cons....

[oblomov]

Why the bias, lets add MPC,OGG,SPC,AC3,AAC,MP3,MP2,WMV,...,ETC why only MP3. There are so many formats, why stop here, lets add video formats as well AVI,MPV,...,ETC hmm, while we're at it how about archive info as well RAR,ZIP,7Z,RK,ARJ,LHA...,ETC.

Now on a more serious note, while I'm all for expanding TC capabilities, some things are very specific and should be left to specific programs. TC is a file manager in the general sense, it's not media library implementation nor should it be.

Uhm. What about a "Find files" plug-in architecture?

[ghisler(Author)]

The difficult thing about a find files plugin is the user interface - how should TC show the additional options? Please consider that there could be dozens of installed search plugins...

[Jonas]

Well, the first simplification is to alow only one active plugin per search. (the lister can also use only one plugin at one time)
If you can't generate a GUI out of information the plugin gives at runtime (like in the exemple above), the plugin could give the interface (as a extra tab of the search-dialog?) but this makes plugin-development more complicated.

An other way could be to use only the 'find text'-field. You would only need an extra checkbox underneeth "use plugins". Then the conent of 'find text' could be the following:
mp3.artist="robbie" AND mp3.vbr=true mp3.playtime<55 OR html.title="[a-z]{10}"
This way is the easiest way to implement but the most complicatet to use (but to most fexible too because you can combine several plugins. If this is sensible is an other question...)

[VadiMGP]

In addition to Jonas's suggestion i can suggest two another approach:

1. Button "Plugin search criteria" in the FileSearch dialog to call plugin-specific dialog box, so every plugin writer can implement own settings dialog.

2. During installation TC can obtain "parameter string" from plugin (like detection string from LS-plugins). This string may looks like Author|Playtime|Title". In the File Search dialog TC can show additional tab for entering parameters value for chosen plugin.

[Hacker]

I'd vote for the extra tab in the search dialog. And maybe some combobox to choose which plugin to use. Or checkboxes and a tab for each chosen plugin. However, this would imply something like AND or OR or something for the results of the plugins.

Roman

[pdavit]

I would also like a new tab for searching network resources like computers and printers and maybe users also. If this is implemented we should see a change in the dialog box title from Find Files to something more general!

[oblomov]

Well, the first simplification is to alow only one active plugin per search. (the lister can also use only one plugin at one time)
If you can't generate a GUI out of information the plugin gives at runtime (like in the exemple above), the plugin could give the interface (as a extra tab of the search-dialog?) but this makes plugin-development more complicated.

An other way could be to use only the 'find text'-field. You would only need an extra checkbox underneeth "use plugins". Then the conent of 'find text' could be the following:
mp3.artist="robbie" AND mp3.vbr=true mp3.playtime<55 OR html.title="[a-z]{10}"
This way is the easiest way to implement but the most complicatet to use (but to most fexible too because you can combine several plugins. If this is sensible is an other question...)

I vote for the "extended find text" field. An idea could be: remove regex search, put "use plugins", and have regex search as a search plugin

regex.text="<regular expression>"

[Jonas]

Why so complicated? If TC supports regex (what TC-6 will do) even the Plugins could use them. (In case the plugin don't geht the seachstring and perform the comparison by itself but forwards the fields to TC)