[PD-dev] Gui plugins management (Was: I have 3 broken installs)

Hans-Christoph Steiner hans at at.or.at
Thu Mar 28 21:26:12 CET 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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).

> an intermediate way could be: - keep the current behaviour of loading all
> 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
> "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)
> 
> similar, though slightly better: - only automatically load a
> 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/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
> ~/pd-externals) - in case this special plugin is not available, revert to
> the default behaviour of loading all plugins in all search-paths (this
> 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)

How about we start with adding only the required mechanism so that people
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJRVKdgAAoJEJ8P5Yc3S76BDYEP/2g8LynLHKqLKV7xnRbH4xuq
P4oPBhH26t6M0j1DF2ldiQPbuDvuMWS6a4nA025Xy4wiNeLuUnhIb6duytFWU36O
gTZNNpP9rJnmIeVQ0nroPzL24Luz2Y9QAhuyPyABGi2nwkbxTWT5seoZeqAbtXYE
CmPhV7Ch97nLMmalQ8B6KoiCrCqO9i2sp7GDh8xxnCJLYMEMzKstFBm4bNvIA/7u
OXY2auJMuVPOj6XaYHqk1iY3UColAsOThh6bfpmK2ekoMWkpqZCoJXF3InztXg+x
VmydyjJUiM0pFDzRYGcMMZR8+CH3N8T4K0Fi0oEjFkRHH9Qz716ENwExmeUegzoO
adSZabGGwGJKbpWWIiJDUEkHa+RnjmjU1tkr+tK7Ql11UTVUXEU1PRlFul88ByL/
rcNAISs/51EODdVdA4ioSJTyNWfwQLOikhTmFOYkBC19Ba3U+SXJISciibhLJJsY
aDUvjNUu8j4MeMD5ZBVbV0t8oIm2mNmbp5/izyCK/3zzuUDXrwVTSIDUTJJkNPlQ
ozY2dO3l9LZPlMIIekhbb1kQwXD9/Jwt2f35nvkUuK/INf1+4Fqk1vX2D8MiBCKk
Wm1ky9wPFzUxZu0O9/NRM+x0kS0BzmDoJf7+KQvJ1q0wGmUWwxXRsDTf25WVc773
TGQyeMp597tgW5o612WA
=eyTx
-----END PGP SIGNATURE-----



More information about the Pd-dev mailing list