An other nice feature of these plugins could be an integration with the multirename-tool. If the plugin returns the value of a specific field, lets say the artist of a .mp3 for comparesion in the search, it could also used for the renaming. You could rename your mp3s using: "[mp3.artist] - [mp3.title].[E]" (I got the idea from KRename, you should take al look!)
The only thing the plugin have to do is to return in initialisation a list of all fields it could fetch and the type of these fields (numbers, bool, text, time, date) and the filetypes it can handle. Later, when in use, it has to return the value of the asked field of a specific file. So it can be used in filesearch and in renaming.
The remeining problem is the userinterface for the search. The 'find text'-field could always be used, but it's not too userfriendly....
If each plugin brings its own GUI the plugins become big and complex and every plugin is different to use. I don't support that.
a tab for every plugin is to much but one extra tab for all plugins would be nice. With a list of all plugins available on the left side and on the right the fields of the selected plugin. Each field has a checkbox in front of it if it should be used or not. If a field of a plugin is checked, it gets a special icon so that you could easyly see if it has checked fields or not. Then perhaps a button 'uncheck all' and the option if the differend fields should be connect by AND or OR.
But in addition the 'find text'-possibility should always work because here you are more flexible with logical relations between the fields.
[Request] Advanced File Search additions...
Moderators: white, Hacker, petermad, Stefan2
I've made 3 fake-screenshots of the search-dialog like I could imagine a userinterface for plugins (ok, the first is an other improvement). Because these modifications need more space, I've put the search-results on a seperat Tab.
http://www.jonas-baehr.de/forum/TC-search_main.png (25k, include/exclude some dir's from search)
http://www.jonas-baehr.de/forum/TC-search_plugin1.png (25k, plugin1)
http://www.jonas-baehr.de/forum/TC-search_plugin2.png (27k, plugin2)
On the left is a list of all plugins available. Each with a checkbox in front of it, if the plugin should be used or not.
On the right is a list of all fields the currend plugin provides. Above two Radioboxes which say if the different plugins should be linked by AND or OR. The two radioboxes on the bottom decide if the fileds of the currend plugin are linked AND or OR.
The Fieldlist itself begins with a list of all extensions the plugins supports. under this are the field of the plugin. each with a checkbox in front. If checked, the field is used for the currend search. Each Field has a name, a type and a default value (may be used to give the user an idea how the data should look like). The type can be 'text', 'date', 'number' or 'multiple choice'.
The Type 'number' can have some external modifiers, like for exemple for the length of an audiofile:
"hour" => 3600, "min" => "60", "sec" => 1
In this case a combobox is shown with these three entries. This tells TC howto interpret the dada from the user. If the user has chosen "min", TC has to multiply the value by 60 before it compares it with the value the plugin returns. If only one modifier is given, it may doesn't have a name. In this case TC simply modifies the data without showing the combobox.
Also possible are internal modifiers. In this case the plugin provides a funktion to modifie the data (may also used for 'text').
On initialisation the plugin tells TC which extension it supports and which fields it provides. Then, if TC has found a file for the plugin to parse, TC passes the filename to the plugin and requests the content of a field. Then TC modifies the userdata (if necessary) and compares it with the return of the plugin.
The Clou: The same plugin could be used for the multirenametool! There you can use "[plugin.field{.modifier}]" in the rename-maks. Here TC requests again the the content of the fields, modifies them if necessary (division by 60 in the case of "min" from the example above) and replace the filename with it. http://www.jonas-baehr.de/forum/TC-multirenametool.png (the seperat box should be calles by the button "[N#-#]")
--
So, thats my concept of the fileextension-plugins for search and rename. What do you think about it? And Christian, is something like this possible?
(I hope you understand my lousy english
)
http://www.jonas-baehr.de/forum/TC-search_main.png (25k, include/exclude some dir's from search)
http://www.jonas-baehr.de/forum/TC-search_plugin1.png (25k, plugin1)
http://www.jonas-baehr.de/forum/TC-search_plugin2.png (27k, plugin2)
On the left is a list of all plugins available. Each with a checkbox in front of it, if the plugin should be used or not.
On the right is a list of all fields the currend plugin provides. Above two Radioboxes which say if the different plugins should be linked by AND or OR. The two radioboxes on the bottom decide if the fileds of the currend plugin are linked AND or OR.
The Fieldlist itself begins with a list of all extensions the plugins supports. under this are the field of the plugin. each with a checkbox in front. If checked, the field is used for the currend search. Each Field has a name, a type and a default value (may be used to give the user an idea how the data should look like). The type can be 'text', 'date', 'number' or 'multiple choice'.
The Type 'number' can have some external modifiers, like for exemple for the length of an audiofile:
"hour" => 3600, "min" => "60", "sec" => 1
In this case a combobox is shown with these three entries. This tells TC howto interpret the dada from the user. If the user has chosen "min", TC has to multiply the value by 60 before it compares it with the value the plugin returns. If only one modifier is given, it may doesn't have a name. In this case TC simply modifies the data without showing the combobox.
Also possible are internal modifiers. In this case the plugin provides a funktion to modifie the data (may also used for 'text').
On initialisation the plugin tells TC which extension it supports and which fields it provides. Then, if TC has found a file for the plugin to parse, TC passes the filename to the plugin and requests the content of a field. Then TC modifies the userdata (if necessary) and compares it with the return of the plugin.
The Clou: The same plugin could be used for the multirenametool! There you can use "[plugin.field{.modifier}]" in the rename-maks. Here TC requests again the the content of the fields, modifies them if necessary (division by 60 in the case of "min" from the example above) and replace the filename with it. http://www.jonas-baehr.de/forum/TC-multirenametool.png (the seperat box should be calles by the button "[N#-#]")
--
So, thats my concept of the fileextension-plugins for search and rename. What do you think about it? And Christian, is something like this possible?
(I hope you understand my lousy english
)
Last edited by Jonas on 2003-09-12, 10:51 UTC, edited 2 times in total.
-
ghisler(Author)
- Site Admin
- Posts: 48232
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Yes, this is a very clever solution. I'm already considering something like this, but it's probably too late for 6.0 - I will keep it for 6.5. I'm sure that I will have some time this Winter to implement it.
What I dislike is the separation of search settings and content. I will probably put the plugins on their own page instead of re-using the advanced page.
What I dislike is the separation of search settings and content. I will probably put the plugins on their own page instead of re-using the advanced page.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Well, here, in the german board, you said that you like the idea with the lists of dirs/settings to include/exclude from search, like on the first fake I made; so the dialog will never the less get too big to show searchresults underneath. And this are options which have to go on the general-tab. Thats why I've put the plugin under the advanced-tab.ghisler(Author) wrote:What I dislike is the separation of search settings and content. I will probably put the plugins on their own page instead of re-using the advanced page.
If the result is on an exrta tab you can't see the search-settings at the same time, thats right. but you have some other advantages: First, you see more enries at once. And you have the option of showing more infos and bottuns, "save results", or "feed to container"...several result-tabs and a bar for sorting the results along size, path, extension, filename or date.... There are many improvements that could be made to the search-dialog in the future. So I think that in long view you woun't have enough space to show all these features together with the seach-settings.
Jonas!
Jonas,
I want to thank you for all the time, effort, and great deal of thought you have put into this suggestion & this thread.
You took a rather simple request that I made, ran with it, looked at it from every angle, and worked out the plausible ways it could be integrated into TC.
And finally, you applied that knowledge into making fake screenshots illustrating how everything would come together on the screen & in the program.
Great job! Christian ought to put you on the payroll.
I want to thank you for all the time, effort, and great deal of thought you have put into this suggestion & this thread.
You took a rather simple request that I made, ran with it, looked at it from every angle, and worked out the plausible ways it could be integrated into TC.
And finally, you applied that knowledge into making fake screenshots illustrating how everything would come together on the screen & in the program.
Great job! Christian ought to put you on the payroll.
An other realy nice task for this fouth plugintype could be the comparison by content. Since the plugin can provide information for wich filetypes (either by extension or a formatstring like for the lister plugins) is was made, the comparison by content could also use this if the plugin is matching on both sides.
In fact TC could generate two tmp-textfiles with the information of these plugins and compares them. The textfiles could have this strukture:
Name of 1st plugin matching on both files
key: value
key: value
...
Name of 1st plugin matching on both files
key: value
...
...
The output in the both panels could look like this:
The forth plugin-type would so propose thre different aplications with the same file: search, multiremane and comparison by content
In fact TC could generate two tmp-textfiles with the information of these plugins and compares them. The textfiles could have this strukture:
Name of 1st plugin matching on both files
key: value
key: value
...
Name of 1st plugin matching on both files
key: value
...
...
The output in the both panels could look like this:
Code: Select all
test1.mp3 | test1.ogg
<mp3tag> | <mp3tag>
Artist: [color=red]My Self[/color] | Artist: [color=red]myself[/color]
Album: First Tries | Album: First Tries
Comment: | Comment:
Track: 1 | Track: 1
|
<audio> | <audio>
Length: 2:34 | Length: 2:34
lossless: no | lossless: no
...
Congratulations, the content-plugins are realy well done. Exactly as I've imagined them. The representation in the search-dialog is even better! I think I'll use this way too...
To be honest: I've had the hope to implement it in Krusader before this feature is in TC, but this time you're won the round
To be honest: I've had the hope to implement it in Krusader before this feature is in TC, but this time you're won the round