Choosing which lister plugin to use in runtime

[nsp]

2Hacker
We need to hear Ghisler: can he implement it?
(I don't think he can...)

Knowing that you cannot load it before loading it is quite difficult to guess

But :
An intermediate solution could be to have a list of "potential" loadable plugin using the file type filter(1) for the current file.

A popup or a menu can show this list and let the user "try to load" a particular plugin if it fail a popup warn " xxx.wlx not loadable fort this file" and remove it from the list of available plugin for this file. The previously loaded plugin is back !

This solution is doable because we use a list of "potential" plugin that is already exploited by TC. The user chose the plugin to load (try) but do not alter TC forcing a plugin just giving a hint on which one should be loaded next.

(1) The plugin file Filter is the definition done when you add a wlx plugin describing type extension,.... ex: ext=reg|ext=ini|ext=inf

[Alextp]

2nsp
That will be weird feature IMHO...

[Huggy]

Hi,

The proposed solution by nsp looks very interesting to me.
It does not matter indeed if the plugin fails the first time trying to lload it, as soon as it is nicely explained to the user.

Anyway, the use of such a menu would be most useful to allow user to quickly switch to a needed plugin which he knows about.

Stéphane

[m^2]

2nsp
That will be weird feature IMHO...

A also think so.

[ghisler(Author)]

Well, when lister knows that a plugin supports a file, then it's already too late: Lister asks the plugin to show the file with ListLoad - and it either returns zero if it doesn't support it, or the handle of the displaying window if it does. There is no function "do you support this file" to ask the plugin whether it can handle the file or not...

[Alextp]

As I said.

[Huggy]

Another solution then : is it not possible to list them all, and the user would then be able to choose the one he wants to use.
Only if he doesn't know his plugins well, will he sometimes receive an "Unsupported file" warning.

Does this seems feasible ?

Stéphane

[nsp]

Well, when lister knows that a plugin supports a file, then it's already too late: Lister asks the plugin to show the file with ListLoad - and it either returns zero if it doesn't support it, or the handle of the displaying window if it does. There is no function "do you support this file" to ask the plugin whether it can handle the file or not...

I fully agree with your analyze !

The Alternate proposition is :
A) Give a list of ALL lister that fits file filter.
B) Show This list
C) LET THE USER CHOOSE NEXT PLUGIN TC SHOULD (try to) LOAD
if plugin load : (return the window handle) show it !
else : give back a warning message and load back the previous plugin.



The main idea of the alternate solution is to give the control to the user to choose which lister should be loaded next !

I'm using a lot some file where 4/5 listers are used, And i know which one i want to use but i'm forced to use 4 key to switch from one to another.


This is not :
- predicting which file is compatible with which lister.
- forcing to use a plugin that do not load.

[Huggy]

The main idea of the alternate solution is to give the control to the user to choose which lister should be loaded next !

I'm using a lot some file where 4/5 listers are used, And i know which one i want to use but i'm forced to use 4 key to switch from one to another.

Precisely ! This is what I have in mind as well ...

[mnandi]

I found a TC utility "OpenFileTC" which written to apply different editors by F4 depending on file extensions. I installed this utility twice, first as F4 and second as Alt-F3 key activation. Thus I can assign a lot of programs to a file extension to view and edit a file.
This program enables fix and graphically choosable program assotiations.

[dott]

There are more:
F4Menu
OpenFileTC
ChoiceEditor
ChoiceEditor_patched