Feature: Allow DIY Plug-ins Management

[analytics]

My apologies in advance if this is already in PDN v4 - I'm still using 3.5 for work and have not had a chance to try it.

Currently, all plug-ins' dlls need to be put into Effects folder. That's all good, but after a while, this folder ends up being a mess - full of dlls without having a clean and easy way to know which ones are from which pack. It's very hard and time consuming to remove packs one no longer wants. Etc, etc.

Solution: Simply make PDN look not only in Effects folder but in any subfolders there too. That way, one would be able to simply create a folder with arbitrary name, paste all the XYZ pack's dlls there and use them. If that pack is no longer needed or wanted, deleting that folder would cleanly remove it. This would also allow one to organize plug-ins in any way one wants and track what's installed, etc. Many other benefits too. I think this would be one great feature!

What do you say? Please feel free to chime in!

P.S. Thanks for all the work by the way.

 

Additional note I forgot to mention originally: this feature would search recursively through subfolders for dlls, i.e. not only first level, but any depth.

 

Edited April 4, 2015 by analytics

[racerx]

Great idea if it would work that way. I have a felling it doesn't, otherwise that would've been done long ago.

[Red ochre]

You should find this useful for identifying which .dll goes with which plugin, especially if you are on Pdn 3.5.11

http://forums.getpaint.net/index.php?/topic/29308-the-plugin-browser-updated-2015-24-01/

[analytics]

Perhaps, some of PDN's direct contributors could comment on recursive-folder-plug-ins loader feature from the design perspective and how much time it'd take to implement it?

 

Thank you.

[Ego Eram Reputo]

There is ONE developer: Rick Brewster. He makes the design decisions AND implements them

Rick has mentioned in the past that it's not a good idea to use sub-folders to 'hide' plugins and stop them from loading. My interpretation is that recursive scans have not been ruled out. Which is not to say that Rick is going to add them, just that he has reserved this space.

[MJW]

I like the idea of subfolders, but I thought I'd mention a problem that might occur for some people. When I download plugins, I normally copy the Zip file into my Effects folder and unZip it there.  This results in a subfolder containing the plugin DLL. I usually cut-and-paste the DLL into my main Effects folder and delete the subfolder.  I suspect others may copy the file into the Effects folder, but leave the subfolder with the original file. That might possibly cause a problem when PDN loads the same plugin twice. I know I've had problems when I've loaded two plugins which share certain internal information, such as the plugin name. I don't know if there's a problem with loading two identical plugins.

[BoltBait]

I normally copy the Zip file into my Effects folder and unZip it there.  This results in a subfolder containing the plugin DLL. I usually cut-and-paste the DLL into my main Effects folder and delete the subfolder.

It is best to do that on your desktop.

[MJW]

That's probably right, but I was concerned that others might do it the way I do, which may not be the ideal approach, but seems to me to be the more obvious one.

[MJW]

A compromise solution, which might minimize the chance of problems, is to only open subfolders which have "Effects" as the beginning of their name, such as "Effects Blurs".

[MJW]

Another method of reducing unexpected problems would be to make it an optional feature that was disabled by default. Anyone who enabled it would (presumably) know enough to clean his or her Effects folder of subfolders containing DLLs that are non intended to be loaded at start-up..

[Rick Brewster]

Recursive scanning wasn't done because ... I don't know. The effect plugin loader was written something like 10 years ago. 

[analytics]

Adding some setting is nice, but involves additional dev work as well as writing additional instructions / explanations. Feature like this is not easy to explain to someone non-technical - i.e. how Effects folder should be cleaned and why prior to activating recursive feature. So if all that could be avoided and make things simpler, the better.

One approach to achieve this, i.e. preventing same dll from being loaded twice or more times (e.g. one unzipped into a subfolder under Effects, and one copied into Effects folder) is to enforce 'first-found-first-loaded' procedure - as the dll is loaded, file hash is added to loaded-dlls collection list so that the exact same one found elsewhere is skipped. This would avoid any need for GUI settings and other complications, plus feature could be shipped enabled without any worry. There could be some other things to watch out for, e.g. versioning, but nothing too complicated to do.

 

 

Another method of reducing unexpected problems would be to make it an optional feature that was disabled by default. Anyone who enabled it would (presumably) know enough to clean his or her Effects folder of subfolders containing DLLs that are non intended to be loaded at start-up..