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

[András Murányi]

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.

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