AkulaBig wrote: ↑2023-06-26, 18:58 UTC
If the number of viewed files increases, then why can't the detect line be changed? Normal solution.
yes once in a while but if the detect string changes with every new release of a plugin its bad coding...
fact still stands: only tc should change the wincmd.ini never plugins, so if the detect string changes uses can either un/install the plugin or edit the wincmd.ini
Sir_SiLvA wrote: ↑2023-06-26, 19:13 UTCor edit the wincmd.ini
The tricky problem - user somehow has to figure out what to edit.
Year after year I just replaced the .wlx and .wlx64 files in the archive.
After this thread, I uninstalled all my wlx plugins and reinstalled them from scratch. It turned out that 10 out of 49 plugins have new detect strings. And there's no way to know the default string, because this information only inside the plugins, not in the readme files.
"I used to feel guilty in Cambridge that I spent all day playing games, while I was supposed to be doing mathematics. Then, when I discovered surreal numbers, I realized that playing games IS math." John Horton Conway
LonerD wrote: ↑2023-06-27, 00:18 UTC
The tricky problem - user somehow has to figure out what to edit.
Year after year I just replaced the .wlx and .wlx64 files in the archive.
After this thread, I uninstalled all my wlx plugins and reinstalled them from scratch. It turned out that 10 out of 49 plugins have new detect strings. And there's no way to know the default string, because this information only inside the plugins, not in the readme files.
Yes, very annoying. That's exactly the reason why I suggested an improvement in the 5th message of this post.
LonerD wrote: ↑2023-06-27, 00:18 UTCAnd there's no way to know the default string, because this information only inside the plugins, not in the readme files.
Should plugin authors add that piece of information to the plugin's readme? Yes, it would be easier for users to get this information, but what would be the benefit, how important is it? There's also a risk that authors forget to update the detect string in the readme when releasing a plugin update.
Both of my content plugins have a section in their readme file dedicated to customizing the detect string. But I'm not sure if there would be any benefit if I put the default detect string there. If a user needs to reset it, it's still possible to just delete it. I'm not sure what to do...
Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
LonerD wrote: ↑2023-06-27, 00:18 UTCAnd there's no way to know the default string, because this information only inside the plugins, not in the readme files.
Should plugin authors add that piece of information to the plugin's readme? Yes, it would be easier for users to get this information, but what would be the benefit, how important is it? There's also a risk that authors forget to update the detect string in the readme when releasing a plugin update.
Tbh imho TC should get a better plugin setup interface and show the detect string in the ini (like TC Plugins Manager does) AND
the detect string the plugin provides...
(yeah, yeah who am I kidding this will never happen...)
Well, both of these things - a (better) plugins manager and a more elaborate plugin readme - are not mutually exclusive. The former will certainly take longer to be implemented while the latter depends on a large quantity of plugin authors...
As I said at the start of this thread: I support a better plugin installation and management interface.
Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
