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: SHA1On 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