Disabled plugin names

[duncanka]

Currently, if a plugin is disabled, it shows up in the Plugins manager not as the true name of the plugin, but as the filename.  Whether this is a bug, an oversight, or (for some strange reason) deliberate, I think it would be more intuitive if the display were consistent.

[mandrav]

This is not an oversight, nor a bug.
The plugin's name is provided by the plugin on request. This means that C::B should load (and create a temp instance of) even disabled plugins.
So, disabled plugins just don't get loaded and their filename is displayed in the management window (so you know they 're there).

[duncanka]

This is not an oversight, nor a bug.
The plugin's name is provided by the plugin on request. This means that C::B should load (and create a temp instance of) even disabled plugins.
So, disabled plugins just don't get loaded and their filename is displayed in the management window (so you know they 're there).

Ah, gotcha.  I see the problem.
But that raises another issue: is there a way to make the plugin information static by DLL?  Maybe have two separate functions for getting the plugin info, one dynamic one (the current getInfo()) and one static one (callable without a plugin instance, and which getInfo() would also call)?  Is there any reason the info has to be initialized in the plugin constructor, and not declared as a static struct?
Sorry if this is a ridiculous suggestion; I don't really know much about DLL linkage.

[mandrav]

Well, this whole info struct could be moved to a separate function, outside the plugin's class. Just like the SDK version functions etc.

[thomas]

That still requires the dll to be loaded though, otherwise you still can't access the name, so it is not much of a gain.

[mandrav]

The DLL must be loaded either way. The point is to not create an instance of the plugin.

[takeshimiya]

Maybe just a "name" setting in default.conf, caching all the plugin names (loaded once upon a time) could do it.

[mandrav]

It's fixed already.

[takeshimiya]