I've been thinking about about a more advanced plugin installation for some time now, and due to recent events I've created a more concrete model of what I'm envisioning.
Some background information.
A while ago I installed a packer plugin that associated multiple extensions with itself. I didn't want all of them associated with this plugin, so I clicked Cancel in the Associate dialog thinking that it would skip only this one file extension. Unfortunately the whole plugin installation was cancelled.
While adding a packer plugin interface to one of my content plugins I was wondering how both of these could be registered upon plugin installation and I came to the conclusion that it's not possible, or required stupid workarounds like separate plugin archives where only pluginst.inf is different.
Here's what I have in mind:
- Installation/Registration of one plugin for multiple plugin types in one pass
- Customizable list of extensions that TC should associate with a WCX plugin
- Customizable detect strings for WDX and WLX plugins
- Customizable name for WFX plugins
Form1
Form2
Form3
Form3 expanded
Whole gallery
Form1 has the drawback that it's too high for low resolutions (like 800x600), but everything is visible. Form2's height is OK but it requires the user to switch tabs to see everything.
The data for the various dialog parts are sourced as follows. [Unchanged] means that it's sourced the same way as currently, [New] means that it requires additional keys in pluginst.inf and new code.
- [Unchanged] $PluginName is sourced from pluginst.inf, section [plugininstall], key "file" (its base name).
- [Unchanged] $PluginVersion is sourced from pluginst.inf, section [plugininstall], key "version". $PluginName could be a fallback in case "version" is missing.
- [Unchanged] $PluginDescription is sourced from pluginst.inf, section [plugininstall], key "description" or "description<lang>".
- [Unchanged] Install target is sourced from wincmd.ini, section [Configuration], key "PluginBaseDir".
- [Unchanged] The packer extensions are sourced from pluginst.inf, section [plugininstall], key "defaultextension".
- [Unchanged] WFX plugin name is the same as $PluginName.
- [New] Plugin type checkbox states are sourced from pluginst.inf, section [plugininstall], key "types". This new "types" key should be a comma-separated list of plugin types, e.g. "types=wcx,wlx", and TC should tick only the checkboxes of the appropriate plugin types from that list. In case the "types" key is not found, it should use the current "type" key instead, i.e. only tick the checkbox of a single plugin type. In either case TC should allow customization nonetheless.
A more advanced approach could be that TC determines the plugin type(s) by itself - by loading the plugin and checking the necessary interface functions - and block the user from ticking checkboxes for plugin types which aren't available/possible. Yes, I'm aware that this requires TC to unpack the plugin before the actual plugin installation, but please see the next point. - [New] The detect strings for WDX and WLX plugins are sourced from calling ContentGetDetectString/ListGetDetectString functions if the plugin isn't already installed. If the plugin is already installed, it should get the detect strings from wincmd.ini instead. TC should allow customization in either case.
Furthermore TC should write the detect strings during plugin installation. The current behavior of writing the detect string during first use is annoying because it requires the user to use the plugin before the detect string can be customized.
Note that this is only about plugin installation, not plugin management because that's another can of worms.
Regards
Dalai