On Thu, Mar 28, 2013 at 9:48 PM, Hans-Christoph Steiner <h...@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 > > <nore...@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
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev