1. When you add a new plugin using configuration dialogs after pressing "Add" - the new window opens for locating the plugin file.
Now the starting directory is the current opened directory - I think it would be better if TC remember the directory which was used previously for adding the plugin (of course separately for different types of plugins: wcx, wlx, wfx).
What do you think about it?
2. In the above window there are filteres for file types (eg. *.wfx). It would be good to add "All files - *.* because there are plugins (eg. Pop3Plugin) which have different extensions (here: .dll).
3. It would be nice to have separate commands to call the "plugin add dialogs" because now all of them are in different places and you have to click and click and click... to call them.
I would like to add them to my menu
Adding plugins - request
Moderators: white, Hacker, petermad, Stefan2
- ghisler(Author)
- Site Admin
- Posts: 48107
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
1: The idea is that you first unzip a plugin, and the the plugin will be in the current dir when trying to install it.
2: Plugin writers should use *.wfx for file system plugins. DLLs are often invisible in standard Windows configurations.
3: Yes, good idea. Maybe I will create a new plugins page in the configuration dialog.
2: Plugin writers should use *.wfx for file system plugins. DLLs are often invisible in standard Windows configurations.
3: Yes, good idea. Maybe I will create a new plugins page in the configuration dialog.
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
But my plugin contains wfx and wcx code in one single file...ghisler(Author) wrote:2: Plugin writers should use *.wfx for file system plugins. DLLs are often invisible in standard Windows configurations.
If it has a wfx extension than you cannot install it as wcx and vice versa
Browse the web with the HTTP SmartBrowserPlugin
Check your mails with the POP3/SMTP EmailPlugin!
Check your mails with the POP3/SMTP EmailPlugin!
: You could have your installer ask the user, how he/she wants to use your
plugin and append the corresponding extension accordingly uppon extraction.
For the .zip-distribution, you could ommit the extension and put an addittional
note in the .zip-file, which have to catch the users eye. Maybe something with
big letters like ATTENTION.TXT.
Since people, who prefer the .zip-distribution over the installer are generally
more advanced, this should ment no big obstacles for them.
plugin and append the corresponding extension accordingly uppon extraction.
For the .zip-distribution, you could ommit the extension and put an addittional
note in the .zip-file, which have to catch the users eye. Maybe something with
big letters like ATTENTION.TXT.
Since people, who prefer the .zip-distribution over the installer are generally
more advanced, this should ment no big obstacles for them.
You are right but even doing it this way, I mean unpacking the plugin form eg. .zip file, my current directory is the directory from which I unpack the plugin, not the one to which I do it.ghisler(Author) wrote:1: The idea is that you first unzip a plugin, and the the plugin will be in the current dir when trying to install it.
E.g.
Left panel: D:\totalcmd\Lister plugins
Right plugin: e:\downloads\wc\anyplugin.zip
So after unpacking the anyplugin.zip the focus (current directory) is still on the right panel.
I never remember to press "Tab" before calling the plugin add dialog
Of course it's not a big bug but sometimes it's frustrating
It could be niceghisler(Author) wrote: 3: Yes, good idea. Maybe I will create a new plugins page in the configuration dialog.
Or not ommit the extension but put as eg. *.wfx and in readme (or ATTENTION.TXT ) leave the info that if somebdy prefer other way of using it he can change the extension into .wcx.deus-ex wrote:For the .zip-distribution, you could ommit the extension and put an addittional
note in the .zip-file, which have to catch the users eye. Maybe something with
big letters like ATTENTION.TXT.
André Martin ,maybe you should make a poll how people use it , maybe people use it only one way
You are right, I also hate installer for pluginsdeus-ex wrote: Since people, who prefer the .zip-distribution over the installer are generally
more advanced, this should ment no big obstacles for them.
It would be great if you could un-/install plugins over a commandline-parameter for TC. So you could create abutton "Add Plugin" and "Remove Plugin" with:
Command: 'totalcmd.exe'
Parameter: '\AddPlugin="%P%N"' ('\RemPlugin="%P%N"')
If the currend file isn't *.wfx|*.wlx|*.wcx nothing happens.
Else the plugin under the curser will be installed/removed.
And for plugin-developer a 'ReloadPlugin' would be nice.
Command: 'totalcmd.exe'
Parameter: '\AddPlugin="%P%N"' ('\RemPlugin="%P%N"')
If the currend file isn't *.wfx|*.wlx|*.wcx nothing happens.
Else the plugin under the curser will be installed/removed.
And for plugin-developer a 'ReloadPlugin' would be nice.
- André Martin
- Senior Member
- Posts: 245
- Joined: 2003-02-05, 15:46 UTC
- Location: Dresden, Germany
2deus-ex & djk
I estimate that over 90% of the users install and use the plugin as wfx plugin because in this way it is a lot easier to use and it provides many additional features.
First I wanted to publish the plugin with wfx as file extension but unfortunatily TC does and did not allow wcx users to install the plugin if it has a wfx extension (they have to rename it first) that's why I chose the "neutral" way (the dll-extension)... It were great if TC would allow to install a plugin depending on the "valid" code and not on its file extension. (Checking against "valid" code means that TC checks if the dll contains the exported function "OpenArchive" for instance - if the user tries/wants to install it as wcx etc.)
Btw. my download statistics say/show that in general 2/3 of the users download and prefer the installer version.
I estimate that over 90% of the users install and use the plugin as wfx plugin because in this way it is a lot easier to use and it provides many additional features.
First I wanted to publish the plugin with wfx as file extension but unfortunatily TC does and did not allow wcx users to install the plugin if it has a wfx extension (they have to rename it first) that's why I chose the "neutral" way (the dll-extension)... It were great if TC would allow to install a plugin depending on the "valid" code and not on its file extension. (Checking against "valid" code means that TC checks if the dll contains the exported function "OpenArchive" for instance - if the user tries/wants to install it as wcx etc.)
Btw. my download statistics say/show that in general 2/3 of the users download and prefer the installer version.