Overwrite detect line of WLX plugin

[AkulaBig]

Added processing of several new extensions to my WLX plugin. When the plugin is automatically updated, the detect line in wincmd.ini does not change, new extensions are not added. If the detect line is removed manually, then a new one is created with all the new extensions. Is it possible to somehow automatically add new extensions to the detect-string?
old detect-line 4_detect=MULTIMEDIA & (EXT="ACR"|EXT="ANI")
Should be after automatic plugin update 4_detect=MULTIMEDIA & (EXT="ACR"|EXT="ANI"|EXT="ARW"|EXT="AWD")

[Dalai]

There's no way I know of to do that. Theoretically a plugin could parse wincmd.ini and delete values from it, but that's much too dangerous for my taste. Maybe you can display a message when the plugin is loaded, just once and save in a configuration file whether or not this message has been shown. The least intrusive way is to highlight that new extensions have been added (in the plugin's history and/or readme) and describe in the plugin's readme how users can update that detect string. This way users can decide for themselves how to deal with such a change.

Nonetheless it would be good if TC's plugin interface had some way to deal with such situations, one that is good for every party involved.

Regards
Dalai

[AkulaBig]

It's clear. Too bad it can't be done automatically.

[Horst.Epp]

There should never be an automatic update of the detection line when a plugin is updated.
This may be handcrafted to select different plugins for certain extensions.

[funkymonk]

There should never be an automatic update of the detection line when a plugin is updated.
This may be handcrafted to select different plugins for certain extensions.

I totally agree!

Still, the way the detect line is managed is not very convenient.

Suggestion:
In "Options -> Plugins -> Configure (WLX)" the detect string is already shown.

What about an "Edit" button to open a dialog for editing the detect string?

This dialog should contain:

1. An editable text box for the actual detect string from the INI (obviously!).
2. A text box with the detect string as reported by the plugin (as reference so to say).
   This text box doesn't have to be editable -- but it should be possible to select substrings, copy them to the clipboard, and paste them to the 1st edit box.
3. A "transfer" button (maybe just a small button with an icon or the like) to directly copy the reported detect string to the actual detect string (overwriting the existing one).
4. OK/Cancel/...

This would make WLX plugin management way easier.

Bonus: A small icon to indicate whether the actual detect string and the reported detect string are equal. Not syntactically equal but equal wrt the extensions.
This icon could already be shown in a new column in the list of plugins. This way, the user can conveniently see for which plugins the detect strings differ.

Any opinions?

[Dalai]

There should never be an automatic update of the detection line when a plugin is updated.

Just to be sure to mention it: I didn't suggest something like this. All changes must be confirmed by the user. The current manual editing is very inconvenient, don't you agree?

Any opinions?

That a full-blown (or at least more sophisticated) plugins manager is missing from TC is one of its long-standing issues. There are several threads and discussions about this topic. Your suggestion sounds good!

Regards
Dalai

[LonerD]

The optimal solution is a new key in [ListerPlugins] for user preferences.
Like this:
0_detect= developer's detect line - always overwrite during update AND during TC startup (or plugin start, because some users like me don't reinstall plugins, but extract a new version and replace old files).
0_detect_user= user's redefined preferences. If present - always use this key. If not present - use default value from 0_detect key.

[Dalai]

2LonerD
Well, that would break compatibility with older TC versions...

[LonerD]

Well, that would break compatibility with older TC versions...

Оlder TC versions can read value from 0_detect= as earlier. So nothing changes.
New TC versions can read value from 0_detect= or 0_detect_user= .

[Horst.Epp]

For me, the way TC handles plugin settings doesn't matter
I use since many years the Plugin Manger, which has all the things TC should have.
https://totalcmd.net/plugring/tc_plugman.html

[Dalai]

Well, that would break compatibility with older TC versions...

Оlder TC versions can read value from 0_detect= as earlier. So nothing changes.

Of course something changes. The detect line gets replaced if I understand your suggestion correctly. This could lead to a loss of modifications a user made to it, if newer and older TC versions are used interchangeably (with the same wincmd.ini).

Regards
Dalai

[funkymonk]

Well, that would break compatibility with older TC versions...

Оlder TC versions can read value from 0_detect= as earlier. So nothing changes.

Of course something changes. The detect line gets replaced if I understand your suggestion correctly. This could lead to a loss of modifications a user made to it, if newer and older TC versions are used interchangeably (with the same wincmd.ini).

Regards
Dalai

For the same reasons given by Dalai, I am also *not* a fan of this suggestion...

@Horst.Epp: True, the Plugin Manger is a helpful tool -- but it's a separate tool.
Imho, if an application like TC supports plugins it should also support a proper plugin management.

The fact that the detect string is not updated once a plugin update comes with a new detect string is quite annoying.
Asking the user to uninstall the plugin first ist cumbersome.
Especially since it is not known whether the detect string will change or not, all plugins should be uninstalled first before an update.
This is not convenient.

@Ghisler Please consider my suggestion. It would allow (1) automatic reporting of detect strings by plugins, (2) user-defined detect strings, and (3) to easily see if the reported detect string differs from the user-defined one.


Just seen this today for the TC IrfanView Plugin

Code: Select all

Version 1.8.6:
+ Added support for EPS,PFB,PRN,PS extensions.
Delete the existing detect string before installation.

Such instructions are not convenient. Some users might not even know what that means and how to do it.

[LonerD]

if newer and older TC versions are used interchangeably (with the same wincmd.ini).

Understand. Fair remark. (although I see no reason to use older TC versions).

Another solution
0_detect= Leave as is (newer and older TC can read this key as always).
0_detect_default= developer's detect line - always overwrite during update with new plugin's settings.
User can see all changes and update his own detect line if he wants.

[Sir_SiLvA]

Just seen this today for the TC IrfanView Plugin

Code: Select all

Version 1.8.6:
+ Added support for EPS,PFB,PRN,PS extensions.
Delete the existing detect string before installation.

Such instructions are not convenient. Some users might not even know what that means and how to do it.

If the User doesnt know what to do with that he can still learn something like we all have, if the user doesnt want to learn that TC doesnt belong in his hands in the first place


Its 100% a bad idea if plugins start to mess with the wincmd.ini and no plugin should do that ever
And having Lister plugins do that is especially a bad Idea in case you got more then one plugin with updated detection string and both try to update wincmd.ini at the same time *shiver*

(apart from the fact that I wouldnt trust a coder who regulary changes the detect string in the first place)

[AkulaBig]

(apart from the fact that I wouldnt trust a coder who regulary changes the detect string in the first place)

If the number of viewed files increases, then why can't the detect line be changed? Normal solution.