-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/28/2013 03:58 AM, IOhannes m zmoelnig wrote:
On 2013-03-27 22:06, Jonathan Wilkes wrote:
I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether.
i'm not talking about PdX. i'm talking about Pd (vanilla): just like the loading of externals is managed in Pd-core, the loading of gui plugins should be managed by Pd-gui. and "managing" should not translate to automatically loading whatever is there. i don't think that a simple plugin manager is too complicated (and needs too much maintainance attention). what's more: if you don't like it, you can always create a pluginmanager-plugin and tell the default pluginmanager to _only_ load the new pluginmanager-plugin, which in turn can do a nicer job.
the problem we are facing right now, is that a lot of gui-plguins get activated automatically, and i have no choice to disable that. at least without switching to my favourite filesystem browser, search for the offending plugin (while the documentation only mentions 2 paths where the plugins can be installed, there are really 3-4 that are always searched, not counting the paths added with "-path", so where the hell should i start searching? how am i to guess that the file "wurdel.tcl" is really the plugin that colorizes all text light-green?) and move it out of the way (after asking my sysadmin for the root-password, since that plugin really was installed somewhere i am not allowed to change files).
an intermediate way could be: - keep the current behaviour of loading all gui-plugins - only install a _single_ guiplugin by default, that in turn loads gui-plugins from _another_ search path. - people can download a more sophisticated guiplugin ("plugin-manager") and replace that "load-all-plugins" plugin. (not really ideal, as it kind of perverts the documentation, where to install plugins; also the "load-all-plugins" is most likely installed with root priviliges, so again i have to ask my sysadmin to replace it)
similar, though slightly better: - only automatically load a specially-named plugin (e.g. "autoloaded-plugin.tcl") that handles the loading of the other plugins. - ideally Pd-gui would only try to load a single plugin of that name (so if you have ~/pd-externals/autoloaded-plugin.tcl and /usr/local/lib/pd-externals/autoloaded-plugin.tcl and /usr/lib/pd-extended/autoloaded/plugin.tcl it will only load the one in ~/pd-externals) - in case this special plugin is not available, revert to the default behaviour of loading all plugins in all search-paths (this would allow to have the old behaviour, but to be easily able to override this behaviour if you don't like it)
all these require to modify the pd-gui. but so does any bugfix (and i'm pretty sure that the solution to bugs is to fix, even if the bugfix might not see much "maintenance" by the original submitter afterwards)
How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin.
.hc