On May 10, 2011, at 2:55 PM, András Murányi wrote:

On Tue, May 10, 2011 at 12:19, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-05-08 18:40, Hans-Christoph Steiner wrote:
>
> Also, I think Pd-extended should include a number of plugins by default,
> like perhaps your completion plugin. So that would mean that the plugin
> reports would be shown by default.

though it's a bit annoying that the user cannot chose to _not_ use a
certain plugin. (moving the foo-plugins folder into a "disabled/" folder
is probably a not such a good idea either, as in this case this would be
a global operation that effects all users on the machine)

(right, there is the plugins-plugin which might solve this; i don't know
about it's persistency though)

If I'm getting right what you mean by persistence, plugins-plugin uses the "move to /disabled" method too. Actually, I don't really sympathise with that method, and I was trying to advocate something else (also because you may not have write access to every folder) and I'll be happy to update the plugin as soon as a cleaner method is agreed on.

Andras

I think its also something that needs to be addressed, but I'm not sure there is a clear idea of how it should be done. I agree there should be some kind of -noprefs/-nostdlib type flag that disables the loading of plugins, perhaps just -noplugins?

The plugins-plugin might be able to override the current plugins loading logic by being loaded first, then breaking out of the loop that loads the rest. That'd be a big hack, but could be an easy way to test out different ideas of handling the loading of plugins.

.hc

----------------------------------------------------------------------------

"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds