-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> an intermediate way could be: - keep the current behaviour of loading all
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).
> 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> similar, though slightly better: - only automatically load a
> "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)
>
> 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) - in case this special plugin is not available, revert to
> ~/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
> the default behaviour of loading all plugins in all search-paths (thisHow about we start with adding only the required mechanism so that people
> 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)
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