To all plugin developers. Let's create plugin installer
Moderators: white, Hacker, petermad, Stefan2
To all plugin developers. Let's create plugin installer
Hello,
Since we have that big "plugin boom" recently, I noticed that there are no standards as in where the plugins are to be installed etc.
I decided to contribute to the "plugin-scene" by providing installator for plugins using NSIS installer in the same way that WinAmp did.
Installer will be automatic, it will create dir for the plugin, copy the files and register plugin with TC (add required entries to wincmd.ini).
It would detect location of TC directory and wincmd.ini, and it would install plugin (with all needed files) using following schema:
$TCDIR\plugins\$plugintype\$pluginname\
where $TCDIR is directory of Total Commander
$plugintype = WLX / WFX / WCX
$pluginname = name provided by author
That way all plugins would be standarised, and (most important with multi-file plugins) in their own directories.
For those not liking having each plugin in separate (it's own) directory, imagine following:
for example plugin001 has readme.txt and plugin002 has readme.txt and they are the same type. Or they both use settings.ini to store their config.
If you have them share the same directory - it may cause problems. That's why I think they best (and clean) way it to keep them in separate directories.
Do you think all plugin entries in wincmd.ini should have path relative to total commander? - that gives you portability, or rather full path to the plugin files?
Do you want one central ini file (for example: $TCDIR\plugins\plugins.ini) - created by installer that would keep settings of all plugins, together with list of all plugins installed on the system?
Let's define some standards here - that will help for sure all TC users, and also you - coz all dirty work with installer will be done by me
Currently installer is in alpha stage and till date following is done:
* modern ui
* multilanguages
* flexible configuration schema
* plugin-specific configuration (txt files)
* Location of wincmd.ini detection
* Location of TC executable detection
* Restarting TC after successfull installation and registering of plugin
* uninstaller (that except files removes all references to the plugin that installer created)
Planned features (todo):
* Registration of plugins (with TC) done 40%
* write plugininfo in registry /SOFTWARE/GHISLER/PLUGINS
* downloading of plugin? (update)
* create an ini file with all plugins information (version, last updated)
[/list]
Since we have that big "plugin boom" recently, I noticed that there are no standards as in where the plugins are to be installed etc.
I decided to contribute to the "plugin-scene" by providing installator for plugins using NSIS installer in the same way that WinAmp did.
Installer will be automatic, it will create dir for the plugin, copy the files and register plugin with TC (add required entries to wincmd.ini).
It would detect location of TC directory and wincmd.ini, and it would install plugin (with all needed files) using following schema:
$TCDIR\plugins\$plugintype\$pluginname\
where $TCDIR is directory of Total Commander
$plugintype = WLX / WFX / WCX
$pluginname = name provided by author
That way all plugins would be standarised, and (most important with multi-file plugins) in their own directories.
For those not liking having each plugin in separate (it's own) directory, imagine following:
for example plugin001 has readme.txt and plugin002 has readme.txt and they are the same type. Or they both use settings.ini to store their config.
If you have them share the same directory - it may cause problems. That's why I think they best (and clean) way it to keep them in separate directories.
Do you think all plugin entries in wincmd.ini should have path relative to total commander? - that gives you portability, or rather full path to the plugin files?
Do you want one central ini file (for example: $TCDIR\plugins\plugins.ini) - created by installer that would keep settings of all plugins, together with list of all plugins installed on the system?
Let's define some standards here - that will help for sure all TC users, and also you - coz all dirty work with installer will be done by me
Currently installer is in alpha stage and till date following is done:
* modern ui
* multilanguages
* flexible configuration schema
* plugin-specific configuration (txt files)
* Location of wincmd.ini detection
* Location of TC executable detection
* Restarting TC after successfull installation and registering of plugin
* uninstaller (that except files removes all references to the plugin that installer created)
Planned features (todo):
* Registration of plugins (with TC) done 40%
* write plugininfo in registry /SOFTWARE/GHISLER/PLUGINS
* downloading of plugin? (update)
* create an ini file with all plugins information (version, last updated)
[/list]
Re: To all plugin developers. Let's create plugin installer
I think it would be better to use Lister, Packer and Filesystem names for plugin types instead of WLX, WFX, WCX. Extensions could change in future, their meaning no, I think.piranha wrote:It would detect location of TC directory and wincmd.ini, and it would install plugin (with all needed files) using following schema:
$TCDIR\plugins\$plugintype\$pluginname\
where $TCDIR is directory of Total Commander
$plugintype = WLX / WFX / WCX
$pluginname = name provided by author
Yes, paths should be relative to the main TC dir.piranha wrote: Do you think all plugin entries in wincmd.ini should have path relative to total commander? - that gives you portability, or rather full path to the plugin files?
I agree: plugins should be defined in a different file so that I could copy my whole plugin dir to another TC and they would be loaded with my configurations at the next TC restart.piranha wrote: Do you want one central ini file (for example: $TCDIR\plugins\plugins.ini) - created by installer that would keep settings of all plugins, together with list of all plugins installed on the system?
I cool feature would be to have a network installer/updated. Look at the "Wassup" plugin for the miranda-icq IM. It gets informations from a central repository about latest plugins/versions so that you can choose what plugin to download/install and periodically check for new plugins or new versions of installed plugins.piranha wrote: Planned features (todo):
[...]
The update process is, in this way, faster and simpler.
Christian and the creator of the installer should find a way to reload plugins configurations and plugin list on the fly without the need to restart TC (like a message between windows that make it possible to unload/reload the plugins).
License #55385
Re: To all plugin developers. Let's create plugin installer
I agree, this would be the target of the whole process. But, due to complexity of plugins, each one of them needs their own installer.bago wrote: I cool feature would be to have a network installer/updated. Look at the "Wassup" plugin for the miranda-icq IM. It gets informations from a central repository about latest plugins/versions so that you can choose what plugin to download/install and periodically check for new plugins or new versions of installed plugins.
The update process is, in this way, faster and simpler.
We could create a program (assuming we have central repository with plugins) that checks for updates, and downloads plugins selected by users and installs them. Each plugin needs tho separate installer that can be run in quiet mode.
That also would be nice feature - but it's dependant on Christian's approach on plugins issue. (modifications of tc)bago wrote: Christian and the creator of the installer should find a way to reload plugins configurations and plugin list on the fly without the need to restart TC (like a message between windows that make it possible to unload/reload the plugins).
- ghisler(Author)
- Site Admin
- Posts: 48118
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
The command cm_UnloadPlugins will unload all plugins. You can send TC the following command:Christian and the creator of the installer should find a way to reload plugins configurations and plugin list on the fly without the need to restart TC (like a message between windows that make it possible to unload/reload the plugins).
wm_InvokeMenuCommand=WM_USER+51
with WPARAM set to the command you want to pass to TC.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- André Martin
- Senior Member
- Posts: 245
- Joined: 2003-02-05, 15:46 UTC
- Location: Dresden, Germany
It is an nice idea but some plugins are really "problematic" - my plugin is a really good example: Just read the upgrade instruction in the readme file and you will find out what I mean - this was also the reason why I wrote an own installer for my plugin.
Browse the web with the HTTP SmartBrowserPlugin
Check your mails with the POP3/SMTP EmailPlugin!
Check your mails with the POP3/SMTP EmailPlugin!
Hmm.. Don't see anything that can be so problematic..André Martin wrote:It is an nice idea but some plugins are really "problematic" - my plugin is a really good example: Just read the upgrade instruction in the readme file and you will find out what I mean - this was also the reason why I wrote an own installer for my plugin.
What you do with install/upgrade ?
Kill TC/Open TC/Modify TC config... Copy files.. Do registry entries.. Modify ini files..
Do it if file exist, or not...
Pretty simple thing.. Everything can be scripted, depending on the need.
- fabiochelly
- Power Member
- Posts: 603
- Joined: 2003-02-05, 12:03 UTC
- Location: Rambouillet, France
For Inno setup users, I created an .iss script to install WFX files.
It checks Ini file and can update an already installed plugin or add a new one in wincmd.ini
It can be easily adapted to all WFX plugins (and WCX or WLX also)
It checks Ini file and can update an already installed plugin or add a new one in wincmd.ini
It can be easily adapted to all WFX plugins (and WCX or WLX also)
Fabio Chelly.
#60241
Lorsqu'on s'occupe d'informatique il faut faire comme les canards...
Paraître calme en surface et pédaler comme un forcené par en dessous
#60241
Lorsqu'on s'occupe d'informatique il faut faire comme les canards...
Paraître calme en surface et pédaler comme un forcené par en dessous
- André Martin
- Senior Member
- Posts: 245
- Joined: 2003-02-05, 15:46 UTC
- Location: Dresden, Germany
- André Martin
- Senior Member
- Posts: 245
- Joined: 2003-02-05, 15:46 UTC
- Location: Dresden, Germany