Total Commander

There are some very nice plugins that could execute some functions on TC startup.

Like, that ACE Helper task manager can show CPU histogram while TC is running etc. Or some updater plugin can check for new TC or plugin version at startup, etc...

My suggestion is to add additional API constructs to all plugins so they can be called on TC startup. This also requires additional interface to set startup plugins.

Currently plugin is aware of its existance only when acctually used. It would be good to have chocie to be aware of TC running.


This can also be used for new kind of plugin, that one witch can set some options on TC startup that are impossible to set now without automatition programs.

Support ++
It will be very useful for some tasks. For example, i can add some functions to my mail plugin, like background mail checking (now i can add and execute this only through separate executable file).

I was also thinking about it. But "startup" is not a good name - background would be better. There were some requests to make FTP server out of TC. It would be nice to have a background defragmenter.
Or thumbnails creation.
And - something that would be much more interesting, but needs VERY close relations with TC (and I have no hope for it beeing implemented before 10.0) - precaching. Some wdx plugins wor k slowly...
Or file indexing - for faster searching.
But I still think that total plugn interface redesign is the way to go - having 8 plugin interfaces (4 existing and 4 requested) hardly makes sence..

BTW: Launch plugins at startup.

Roman

BTW, there is a way to add startup plugins NOW.


You create dummy content plugin and set it to be in every view during plugin installation.

Procedure:

• 1. For your plugin X that you want to be start up as soon as TC starts, create function AtStartup() and export it. This one should do resident stuff.
  
  2. Create content plugin CX that will load dll X, call AtStartup() function first time it is called for value by TC and return imedately on succesive calls. CX might check here are there any new views defined in the meantime to add itself at the end.
  
  3. Among the plugin X options, add checkbox [ ] execute at TC startup. When clicked scan for TC defined custom views within its ini file, and add dummy field of CX at the end of eatch field array. Set the colum width to be 0.
  
  Next time when TC is started it will call CX when it is about to display information for the first file in the panel. So it will call CX and this plugin will load X and return as fast as possible in succesive calls so not to influence the speed of panel display, as once X is loaded, there is no more work for CX.

Well, it will work, just don't mention this to Ghisler. He is too sensitive about such kind of "dirty tricks"

Next time when TC is started it will call CX when it is about to display information for the first file in the panel.

Does TC really call a content plugin on start even if no custom columns are shown? Isnt there a flaw in the design then?

I'm sure it doesn't. I can normally delete a plugin.

Read again:

3. Among the plugin X options, add checkbox [ ] execute at TC startup. When clicked scan for TC defined custom views within its ini file, and add dummy field of CX at the end of eatch field array for eatch view. Set the colum width to be 0.

This means, that CX will be set as a last field for ALL views you defined for TC. So, no matter how close or open your TC (i.e. with what view was active before closing) it will still start with the view that has CX as the last column.

Basicly, CX does the same as the user added it manualy but without its knowledge.

The drawback: When you edit your views you will see CX floating at the bottom. Not really a problem....

NOTE: This can be created this way.

• - CX becomes general Plugin Loader content plugin. U put plugin names you want to load in the ini file CX can read
  - At the startup CX call AtStartup() function for all plugins in its ini file. Plugins must expose this function the same as if Ghisler officialy announced it. Then it checks for new views to update itself as a last column in eatch view.
  - CX returns imediately on succesive calls by TC.

Its nice, as a plugin author U only have to write single function, AtStartup() and if user has Plugin Loader content plugin installed it can use it, otherwise, it will be ther wasting space...

I found another way to load plugins at startup. It also a little twisted way but I personally satisfied.
I've created a dummy wdx plugin and used it for coloring by its field with coloring condition that never meets, so it doesn't affect current coloring. This plugin in his turn load all others plugins. It works. Only limitation - user have to define coloring by type.

Christian,
could you please write what are your plans about it?
I'm considering making TC support such interface..in a way that's more brute , but cleaner than VadiMGP's one..with code injecton.

I currently don't plan to auto-load any plugins. If a plugin needs to run all the time, it should install a separate program which adds itself to the Autostart/Startup group. The plugin can then either use the data created by that program, or communicate via pipes/dde/whatever with the program.

Thanks for the answer.
So I'm writing it.
I don't know yet what can I do with such interface, startup of plugins for sure, but maybe more.
Anybody willing to write something for unofficial interface?

2m^2

So I'm writing it.

Can you explain a little what you intend to write?

Anybody willing to write something for unofficial interface?

Interface for what? As you wrote youself

I don't know yet what can I do with such interface,

If you don't yet decided what is purpose of the interface, how do you want to write definition?

It is realy good idea to add startup interface to TC.
Writing TotalConsole plugin I found the necessity for this.