On May 10, 2011, at 2:55 PM, András Murányi wrote:
On Tue, May 10, 2011 at 12:19, IOhannes m zmoelnig <[email protected]>
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
