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

András Murányi muranyia at gmail.com
Thu Mar 28 23:34:00 CET 2013


On Thu, Mar 28, 2013 at 9:26 PM, Hans-Christoph Steiner <hans at at.or.at>wrote:

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

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.
Then the management plugin would take care of discovering, enabling,
disabling plugins, and updating the list.

András
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130328/be5f16b6/attachment.htm>


More information about the Pd-dev mailing list