[PD-dev] [ pure-data-Patches-3609350 ] prevent recursive loading of gui-plugins

[András Murányi]

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

> On 03/28/2013 07:17 AM, András Murányi wrote:
> > On Thu, Mar 28, 2013 at 12:42 PM, SourceForge.net
> > <noreply at sourceforge.net>wrote:
> >
> >> Patches item #3609350, was opened at 2013-03-28 04:42
> >> Message generated for change (Tracker Item Submitted) made by zmoelnig
> >> You can respond by visiting:
> >>
> >>
> https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_id=55736
> >>
> >> Please note that this message will contain a full copy of the comment
> >> thread,
> >> including the initial issue submission, for this request,
> >> not just the latest update.
> >> Category: puredata
> >> Group: bugfix
> >> Status: Open
> >> Resolution: None
> >> Priority: 5
> >> Private: No
> >> Submitted By: IOhannes m zmölnig (zmoelnig)
> >> Assigned to: Miller Puckette (millerpuckette)
> >> Summary: prevent recursive loading of gui-plugins
> >>
> >> Initial Comment:
> >> if a gui-plugin loads other plugin, we might easily encounter a
> recursion
> >> (where the plugin tries to load itself).
> >> while the current gui-plugin loader mechanism tries to prevent
> re-loading
> >> of the "same" plugin (based on the filename of the plugin), it doesn't
> >> catch recursive loading.
> >> the attached patch fixes this, by adding the to-be-loaded plugin to the
> >> "::loaded_plugins" list, then tries to load it and removes it from the
> list
> >> if the loading fails
> >> (rather than adding the plugin to the list after the loading succeeded)
> >>
> >>
> >
> > Some minor comments from the perspective of the current plugins-plugin
> > which you may or may not want to consider:
> > - the plugin creates a ::plugins_loaded list which is almost the same as
> > ::loaded_plugins with the difference that "-plugin.tcl" is stripped and,
> > more importantly, brackets in the name are stripped too because they can
> > cause weird things when handling the strings in tcl.
> > - for the sake of tidiness, the plugin introduces a ::plugins namespace
> > where all the functions go.
> > - what about splitting the whole plugin stuff out into a new
> pd_plugins.tcl
> > so that we don't have to worry too much about bloating pd-gui.tcl?
> > FYI: current plugins-plugin is cca. 200 lines, of which obligatory
> protocol
> > is 20 lines, switching mechanism is 40 lines, meta extraction is 60 lines
> > and building the dialog box is 70 lines - thought this may assist the
> > decision about what to maintain inside pd and what to leave in a plugin.
> >
> > My 2 cents are that the moving-the-file way of managing is ugly and a
> list
> > of enabled plugins shall be maintained in the preferences. Pd-gui could
> > load everything (or nothing) by default, letting a plugin modify the
> list.
> > So it would at the end take only a few extra lines in core pd gui.
>
> Users currently install plugins by putting them in a folder.  Plugins are
> managed via whatever preferred file management the user likes.  Plugin
> managers can easily do the same.  Then users who are used to doing it via a
> file browser will still be able to do that whether or not they are using a
> plugin manager.  And installing and managing plugins both happen by moving
> files around.
>
> There needs to be a consistent experience here, so the management process
> should not be different than the installation process.  I don't see any
> real
> advantage to adding complexity to installing plugins when dropping it into
> a
> folder is enough.
>
> What particular problems are there with using the DISABLED/ folder?
>
>
The folder may not be writable for the pd process, it may be shared with
other users or pd installations and the /disabled/ folder is "ugly", in the
sense that if every software vindicated the right to use this method then
our folders would look like the favella. I never liked special mac folders
appearing here and there either.
I also don't think there needs to be any consistency between the file
manager method and the plugin manager's way. If you put a file in the path,
it's found, if you remove it, it's gone - it's something profoundly obvious
which applies to every software which uses a file system. We do prefer
managing loading with some other mechanisms though - we don't make
/disabled/ folders for disabled pd libs, do we?

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