A PROGRAM to create a setup for each plugin

[fabiochelly]

Last week I created a script to generate a setup for each plugin.
The latest version of this script can now uninstall also the plugin.

To simplify the process, I now have included the script with a GUI program (TCPlugin) that will create the setup without needing any complex manipulation of script or compiler.

Install TCPlugin.exe
Now, without installing NSIS on your computer, you just need to specify the folder where your plugin files are located and the program will do the rest.

Screenshot: http://totalcommander.free.fr/fabio/tcplugin.png
Program setup: http://totalcommander.free.fr/fabio/tcplugin.exe
Program sources: http://totalcommander.free.fr/fabio/tcplugin_sources.zip

[fabiochelly]

New version:

- You can now choose if the uninstaller has to be created or not
- You can now create multiple languages setup

Screenshot: http://totalcommander.free.fr/fabio/tcplugin.png
Program setup: http://totalcommander.free.fr/fabio/tcplugin.exe
Program sources: http://totalcommander.free.fr/fabio/tcplugin_sources.zip

[chriss]

hi

great idea! great tool!

big thanx for it.

[djk]

Well, it looks nice but... I'm not sure if I'd like authors of plugins use it. Why? I like to have control on my computer and I prefer manual installation if I can choose.
If authors will use tcplugin and will be publishing only exe versions of plugins I.. won't be happy.

IMHO it would be better if there was a tool (similar to tcplugin) which would create for authors a package with the name like... myplugin.wlxplugin or myplugin.wfxplugin. Tha package could contain all the plugin files and automatically created file with info and configuration for installation (eg. in .xml format). But it should be typical .zip file (with the earlier mentioned extensions).
There should be also application (of course it would be better if it was a function of TC itself) which would support the files with these extensions.

This way plugins could be installed automatically but if anyone would like to do it manually, he would be able to easily unpack the package himself.

[Ergo]

I made first installation for new plugin
http://www.totalcmd.net/plugring/PdbView.html

[djk]

I made first installation for new plugin
http://www.totalcmd.net/plugring/PdbView.html

Now I'm sure... I don't like this way of plugins distributing. I'm even not able to see the readme file.

[fabiochelly]

I made first installation for new plugin

Great!

Now I'm sure... I don't like this way of plugins distributing

TC is a windows program and many user don't know how to manage files and zip archives.
And even for advanced users, it's very boring when I need to install many plugins one by one manually on a new system.

Look at Winamp: the success of this program comes mainly from the plugins and those plugins use exe setup because many of their users are not able to unpack zip archive and place it in the right folder.

Many people I know (and avanced computer users) never try to install plugins because they feel lazy about installing manually the files and registering the dll in TC (all my colleagues use TC at work).
Since I created my script, I created a setup for each plugin we use at work and put them on the intranet. Now, everybody has all plugins installed and play with them everyday.

Anyway, would you like a checkbox in the setup:
'unpack files only' (no registering)
Like that, if you check this box, the setup is nothing more than a SFX archive.

I'm even not able to see the readme file

It's possible to include a license or a readme file as the first page of the installer. Like this, you would be able to see the readme file just by clicking on the exe

[Sheepdog]

I tried to male a setup for one plugin. It seemed to work properly but I cannot locate the setup file nor do I know the name.

sheepdog

[djk]

2fabiochelly
I'm not against the idea of such a tool. As you can see above I also support it but I'd like to have a choice.
I also provide all the current plugins for my colleagues but the main problem for most of them was not unpacking the files and installing them manually but... knowledge of English (sometimes Russian) . Of course I also know many people who has never installed any plugin but usually because they don't know they need it or just really don't need it.

Coming back to your script:
- 'unpack files only' it could be a good idea.
- It would be good if it remember last used path for next using.
- Installing may cause some problems e.g with .ini files. What should be done if I install new version of plugin? Should I overwrite the existing one? Maybe it should copy new one as eg. plugin.ini.new or make backup of old ones?
- Readme is often in two languages so... which one to choose during installing?

[Sheepdog]

Now I found the setup file (I clicked the dialog to fast away).
As djk mentioned - there are some things to improve:

- it would be a good Idea if the program remembers the last folder (and the language and if uninstall desired or not)

- I have made a setup for the PluginManger. There is the TC Path required in the ini-file. The setup doesn't adapt this path - so PluginsManager will not work.

- I ticked the uninstall checkbox, but there is no option to uninstall the plugin in the setup.

- when I selected my plugin-folder the name and mainfile of the first plugin is suggested. But when I select another plugin-mainfile the pluginname remaines. It should change or at least disappear, I think.

But this program is a good Idea.

sheepdog

[fabiochelly]

it would be a good Idea if the program remembers the last folder

Yes i will improve the program to remember last entries but I think djk is talking about the latest install path for updating a plugin: this is already the case; if the plugin has already been installed, the setup will automatically propose the same folder.

There is the TC Path required in the ini-file

I don't understand: the TC Path can be automatically calculated (that's what script does)

I ticked the uninstall checkbox, but there is no option to uninstall the plugin in the setup.

If you check the uninstall checkbox, an uninstall.exe file will be created in the plugin folder. Execute it to remove the plugin.

when I selected my plugin-folder the name and mainfile of the first plugin is suggested. But when I select another plugin-mainfile the pluginname remaines. It should change or at least disappear, I think

Yes you're right. I calculate plugin name and mainfile when you select the folder only. I should calsulate also the plugin name when you change the mainfile.

Readme is often in two languages so... which one to choose during installing?

For advanced functions, it's always possible to change manually the script (proposing one license page for each language is very easy with NSIS).

[djk]

it would be a good Idea if the program remembers the last folder

Yes i will improve the program to remember last entries but I think djk is talking about the latest install path for updating a plugin: this is already the case; if the plugin has already been installed, the setup will automatically propose the same folder.

You are right. I thought about the destination of plugin (or unpacking package) but I think both problems can be important. In my problem the path should be probably saved in any .ini file at user's computer.

[fabiochelly]

As the plugin is registered with its path in TC ini, it's the best place where to find the previous install folder

[Sheepdog]

There is the TC Path required in the ini-file

I don't understand: the TC Path can be automatically calculated (that's what script does)

The PluginsManger.ini (from Pluginsmanger-plugin) contains the following:

Code: Select all

[TCInfo]
TCPATH=e:\tcbeta\TOTALCMD.EXE
INIPATH=e:\tcbeta\ini\XPPro\wincmd.ini

If the path is not set right the plugin doesn't work. Even the %Commander_path% unfortunately doesn't work for this plugin.

Pluginsmanager package comes without any *.ini file at all. So if I take the folder where the unpacked files are, your prog doesn't create a *.ini file and the plugin doesn't work. If I use an existing and installed version, your TCPlugin takes the existing *.ini file. And if I install the plugin with the created setup, there is simply the copied *.ini file - and than the Pluginsmanger doesn't work. (In the worst case it changes the wincmd.ini of the other installation without desire).
So (in this case) your setup is no improvement for common users but a source of error.

I don't know how to do it, but I think TCplugin should have to read the *.ini files and alter it if there is a path included.

sheepdog

[fabiochelly]

It's not complicated to do with NSIS.
I can show you how to change the script to set your ini values