New WDX field custommatch flag + ContentCustomMatch func

Here you can propose new features, make suggestions etc.

Moderators: white, Hacker, petermad, Stefan2

User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

New WDX field custommatch flag + ContentCustomMatch func

Post by *MVV »

Currently there is no easy way of passing some parameter to content plugin during searching, so we need such a way. Fields of ft_custommatch type should only support one matches operator that will pass entered text to ContentCustomMatch plugin function, and plugin should check if this string (it may be some command, text or just another file name for e.g. checking if this file exists in the same dir) can be applied to the given file. It may be a much more powerful way of searching for text than returning entire file text to TC (which may be ineffective for large files), or it may be a way of performing plugin-specific function with some input parameters.

E.g.:

Code: Select all

someplugin.RawContents matches "abc"
someplugin.DirContains matches "descript.ion"
someplugin.DirContains matches "..\desktop.ini"
someplugin.ImageSize matches "small or medium"
I believe there will be much more applications for such function.
Last edited by MVV on 2017-06-01, 11:59 UTC, edited 1 time in total.
User avatar
Hacker
Moderator
Moderator
Posts: 13052
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Post by *Hacker »

Support++.

Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
User avatar
Lefteous
Power Member
Power Member
Posts: 9535
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

Sounds like a nice idea to me.
We should first clarify how this could be used from a user point of view. Currently the user has to enter a plugin field, an operator and a value. For me it seems plugin field and value would be the same but what is different is actually the operator.

The next question would be if the operator is really field-specific or can be used for all content fields. I currently don't see a reason why these operators cannot be provided globally. This would make the whole thing much more flexible and it's also the more logical solution.

So a plugin field that returns a string 'sometext' would be returned by the plugin. Now TC would call the custom operator called e.g. 'contained in this folder' that checks if a filename with such a string is contained in the folder belonging to the file.
So for the user it would be plugin.field 'contained in this folder' 'sometext'
From the programmers view the function would have at least these params: filename, type and value (void* fieldValue). It would of course always return booleans.

In the end convincing Ghisler is only possible with real-world use cases. If there are only a few he can do it internally. If they are to special he might argue that not many users would use it. A plugin API only makes sense when it's something inbetween.
I think some operators could really be added internally like 'starts with' and 'ends with' as I suggested a while ago.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

So you suggest to add user-defined operators instead of special fields? What will field name do in your case?

And I don't understand why would plugin field and value be the same - field describes an action and value is a parameter for that action...

I thought about an operator that can be used for all content fields, and ContentGetSupportedFieldFlags function could export a flag for fields supporting this operator, in such case parameter could define e.g. some kind of custom format string (for fields that export values other than boolean). I don't know though will it be useful or not.
User avatar
Lefteous
Power Member
Power Member
Posts: 9535
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

So you suggest to add user-defined operators instead of special fields?
Yes
What will field name do in your case?
Same as now
And I don't understand why would plugin field and value be the same - field describes an action and value is a parameter for that action...
Why do you think I do? Of course a field is a field and a value is a value. The connection is that the field retrieves the value. Nothing should be changed about this. This would be confusing.
I thought about an operator that can be used for all content fields, and ContentGetSupportedFieldFlags function could export a flag for fields supporting this operator, in such case parameter could define e.g. some kind of custom format string (for fields that export values other than boolean). I don't know though will it be useful or not.
Try to think about ther use case first and then we can talk about how it could work.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Same as now
Please provide an example where field name and operator name both have sense. In my mind two user-defined names are redundant so they could be merged into one field name so it would be enough one specific operator.
Why do you think I do? Of course a field is a field and a value is a value. The connection is that the field retrieves the value. Nothing should be changed about this. This would be confusing.
In my case value would be used as a parameter for the field, and result would be boolean, while in standard case value is compared with field result by TC.

The first use case is searching for specific files in same dir (this topic). With such feature it could be solved like this:

Code: Select all

someplugin.DirContains matches "DTAR_08E86330_4835_4B5C_9E5A_61F37AE1A077_DTAR"
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

For the user it's better to have separate field name and operator. For example, the operator can be "contains", "contains, ignore case", "does not contain", "regular expression" etc. etc. Now imagine a plugin with 20 fields, and you would have to add 8 or so operators as fields - this gives a list of 160 fields.

The question is why does the plugin have to check for the field instead of returning it to TC, so TC can check it? Is there any technical reason to do this? Can you give me a concrete example where this would be useful? Because the downside is that the plugin author would then have ti implement all these operators by himself.
Author of Total Commander
https://www.ghisler.com
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

ghisler(Author),
E.g. we want to check if a file exists near our file: if we let TC check, we need to return entire directory listing (which can be huge in some folders, and it will be returned for every file) while in case of passing file name to plugin it would be a quite fast check.

Another example may be checking if a file contains some not-adjacent values (e.g. we search for files w/o null bytes)...

So benefits of such parametrized operator are mainly in cases when a plugin should return too much data (or too strange data) to let TC check something instead of just checking it by plugin itself using passed parameter. And, these are special fields that don't need usual TC operators, only special ones, so a plugin writer would need to support only required operators.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

I see - that makes sense. For such fields, it would be best to allow custom operators provided by the plugin, and not require support for standard operators like "contains".
Author of Total Commander
https://www.ghisler.com
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

So we need at least some special field flag (field value must be ft_boolean) and a function that will process field parameters.
Also, if we need multiple operators for a field, we need a way of enumerating operators. Though I think that one generic operator for such fields would be enough (field name can be descriptive enough).
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

There are other possible problems, e.g. the comparison could take several minutes, which would completely block TC. Therefore some sort of background processing would be needed...
Author of Total Commander
https://www.ghisler.com
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Well, you can use the same ft_delayed+CONTENT_DELAYIFSLOW scheme here.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Re: New WDX field custommatch flag + ContentCustomMatch func

Post by *MVV »

I've recalled that feature again but it is still not implemented. Would be nice to see it in TC 10.

I think that custom operator name(s) may be returned in Units field for such fields (because such fields are not for displaying data), since there is no need to change function interfaces.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Re: New WDX field custommatch flag + ContentCustomMatch func

Post by *MVV »

So, isn't it a good time to extend API?
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Re: New WDX field custommatch flag + ContentCustomMatch func

Post by *ghisler(Author) »

This has actually been added recently:
01.03.21 Added: Content plugin interface: New flag contflags_fieldsearch allows to handle the search within the plugin instead of returning the value to Total Commander. Includes 3 new functions: ContentFindValue, ContentFindValueW and ContentGetSupportedOperators (32/64)

The new functions are described here:
https://www.totalcommander.ch/beta/contentpluginhelp212_chm.zip

I solved the operator problem with the new ContentGetSupportedOperators function, so you only need to implement the operators you need.
Author of Total Commander
https://www.ghisler.com
Post Reply