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