More advanced plugin installation

[Dalai]

Hi there.

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:

1. Installation/Registration of one plugin for multiple plugin types in one pass
2. Customizable list of extensions that TC should associate with a WCX plugin
3. Customizable detect strings for WDX and WLX plugins
4. Customizable name for WFX plugins

I've created two mockups:
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.

Maybe someone has a(n even) better idea on how plugin installation could be improved. Maybe someone has ideas how the plugin installation dialog could be improved or should look like. In other words, feedback is very welcome!

Note that this is only about plugin installation, not plugin management because that's another can of worms.

Regards
Dalai

[hi5]

Interesting idea, I would probably add an option to enter "Exclude extensions" as well. I had some trouble figuring out how to formulate it for a lister plugin (got there in the end but having the option to enter "exclude" would have helped)

Checkboxes are nice but perhaps "complicated", a simple CSV list would suffice perhaps?

[Dalai]

I would probably add an option to enter "Exclude extensions" as well.

My idea is supposed to set the detect string in the same format that is saved in wincmd.ini. This includes the option to exclude extensions. Sure, some kind of help text could (maybe even should) be included which describes how to make such exclusions.

Checkboxes are nice but perhaps "complicated", a simple CSV list would suffice perhaps?

I put checkboxes there to allow to quickly and easily unselect extensions the plugin author added. A comma-separated list would have the advantage that users could add even more extensions which the plugin doesn't provide while making it possible to remove any extensions a user doesn't want. The drawback of such a freely editable list is that errors are easier to make. Well, there's always something... Both approaches have pros and cons.

Regards
Dalai

[Hacker]

Dalai,
My apologies, maybe I have missed something, but to me it reads as "I faced some issues while developing a plugin, and they might be solved by using this new interface". From this I cannot really determine for what it would be useful (except the obvious extension checkboxes). Could you please shortly summarize the advantages of this implementation?

TIA
Roman

[Dalai]

Could you please shortly summarize the advantages of this implementation?

Well, the main points are already explained above:

1. Installation/Registration of one plugin for multiple plugin types in one pass
2. Customizable list of extensions that TC should associate with a WCX plugin
3. Customizable detect strings for WDX and WLX plugins
4. Customizable name for WFX plugins

None of these points are limited to plugin developers but they would benefit all TC users in general.

Let me give some more specific examples:

1. Total7zip is a packer plugin. When installing it, TC associates it with the 7z extension. But it can also be installed/registered as a content and even a Lister plugin, but installing it as either of them must be done manually by the user via TC's Options dialog (or editing wincmd.ini). With my idea it would be much easier to do in one step.
   There are other plugins which provide more than one plugin interface type, e.g. TCMediaInfo and my own CertificateInfo (update with WCX interface yet to be released).
2. When installing the MhtUnpack plugin TC offers to associate it with MHT, MHTML, MSG, B64, UUE and XXE extensions. I only wanted it to associate with MHT, MHTML and B64 and skip the rest. Cancelling one of the association dialogs aborts the whole plugin installation process. This makes it necessary to trigger the plugin installation again, letting it associate all extensions and removing the unwanted ones from wincmd.ini afterwards. My idea would make this possible during plugin installation and also much easier.
3. Not all detect strings of WDX and WLX plugins are suitable for everyone, so it would improve plugin installation if TC would allow customization. One person might want to use plugin X while another wants to use plugin Y for the same file type. Some users might want to add extensions to the list implemented by the plugin author. My idea makes it possible to customize both detect strings during plugin installation.
4. Some users have been requesting a customizable WFX plugin name to show in network neighborhood. Currently editing wincmd.ini is the only way to do that. My idea would provide that at least for plugin installation. It doesn't help with changing the name later but we should start somewhere, right?

HTH

Regards
Dalai

[Hacker]

Dalai,
OK, so
1. is mainly to save developers some work, right? The only advantage to users would be that they don't have to download / install two plugins?
2. is for extensions as mentioned above, but IMO this should be changeable at any time in the config, not only during installation
3. is for detect strings, which ordinary users have no idea about, so perhaps the GUI could do more than only allow to edit the detect string?
4. should IMO preferably be solved simply by Shift-F6 in Network Neighboorhood

Roman

[Dalai]

1. is mainly to save developers some work, right? The only advantage to users would be that they don't have to download / install two plugins?

It's not just less work for developers who can then provide a pluginst.inf that tells TC to register the plugin for multiple plugin types. Consider existing plugins (or rather plugin archives containing a pluginst.inf) that won't ever be updated. Users can simply install one plugin and register it for different plugin types. Just like the Total7zip plugin I mentioned. How many users know that some plugins provide not just one plugin interface? Sure, this plugin provides a readme which details that, but not all of the plugins do (like the mentioned TCMediaInfo).

2. is for extensions as mentioned above, but IMO this should be changeable at any time in the config, not only during installation

Of course. But as I said in the OP, the suggestion is only about installation. A better plugin management in TC is necessary regardless. For such management I have no better suggestion than to implement the existing PlugMan into TC, but let's not get distracted here.

3. is for detect strings, which ordinary users have no idea about, so perhaps the GUI could do more than only allow to edit the detect string?

Well, if a user doesn't know what a detect string is, then he/she shouldn't change it. And as said in the OP, TC should get the detect strings from the plugin before the actual installation is done. Experienced users can then change it to their needs and use that immediately. Detect strings can get (very) complex, so I'm not sure what "more than only allow to edit it" you have in mind...

4. should IMO preferably be solved simply by Shift-F6 in Network Neighboorhood

That's only after installation, which has been suggested multiple times in the past. The idea here is to allow users to set the name upon plugin installation, i.e. when a user already knows that the name should be changed.

Regards
Dalai

[umbra]

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.

If understand this right, instead of just reading a plugin manifest, TC would load and execute the plugin whenever a user pressed ENTER on the plugin's archive. That might happen by accident - the user might be unaware that the archive would actually be a packed TC plugin. Worst case scenario, a user somehow receives an archive, tries to open it and it executes a malicious code using admin privileges, since some users tend to always run TC elevated.

If that's what is proposed, TC would have to implement some safeguards to prevent that.

[Dalai]

2umbra
TC would only do the advanced stuff if the plugin archive contains a pluginst.inf because that file is still required (TC wouldn't know if an archive contains a TC plugin, its name, type, file and so on).

This part of the suggestion works like this:

1. TC extracts the plugin from its archive.
2. TC loads the plugin as DLL (like normally).
3. TC checks if specific functions for each plugin type are exported by the plugin, it does NOT execute any of them.
4. TC unloads the plugin and deletes the extracted file(s).

The only place where code could be executed is when the plugin is loaded as DLL (DllMain function). This could be exploited, but so does installing any plugin in TC currently. Unfortunately I don't know if loading the plugin with the LOAD_LIBRARY_AS_DATAFILE flag allows to check a DLL's export table.

Regards
Dalai

[umbra]

Your initial description follows with

The detect strings for WDX and WLX plugins are sourced from calling ContentGetDetectString/ListGetDetectString functions if the plugin isn't already installed.

So TC would have to execute the plugin's code.

My issue is with the initial opening of an archive. You try to open an archive to enter it. TC detects that is is actually a plugin archive (it contains pluginst.inf) and shows the plugin installation dialog. Would that be the dialog that you suggest? If so, the plugin would have already been executed at this time. Or would it be the current one, just notifying that a plugin was detected and that it can be installed, followed by your new dialog?

Because that would give you the chance to stop, if plugin installation wasn't your intention. But it would add an additional step to the process.

[Dalai]

Would that be the dialog that you suggest?

Currently, TC shows a two-step dialog sequence, and I don't want to change that. The first one is the confirmation dialog whether or not to install the plugin. It contains the plugin name, version and description. If the first dialog is confirmed TC shows the second dialog where it asks for the installation directory. That's the one my suggestion aims to replace, or rather expand it, and that's why the mockups also contain a field for the installation directory and a tree button.

Regards
Dalai

[JOUBE]

Would that be the dialog that you suggest?

Currently, TC shows a two-step dialog sequence, and I don't want to change that. The first one is the confirmation dialog whether or not to install the plugin. It contains the plugin name, version and description. If the first dialog is confirmed TC shows the second dialog where it asks for the installation directory. That's the one my suggestion aims to replace, or rather expand it, and that's why the mockups also contain a field for the installation directory and a tree button.

Regards
Dalai

Just write the program independently of the Tc. It's not too difficult - bypassing Tc, so to speak - to write into the ini files. And if - which you can make a prerequisite - the program is started from within a running TC, all the necessary environment variables are available and you can also restart the TC - if necessary - so that the changes take effect.

Then one can test it.

Joube

[Dalai]

2JOUBE
What are you talking about? What program?

[JOUBE]

2JOUBE
What are you talking about? What program?

No need to integrate it in the Tc. Just write an external program with your functionalty.

You already have access to everything: env vars, inis, ...

Joube

[Dalai]

Do you say the same thing about plugin management? Sure, TC Plugins Manager can be used, but it would improve things a LOT if it were integrated in TC.

I made my suggestion for a reason, to see it integrated into TC - just like any other suggestion made here.

Regards
Dalai