On 03/28/2013 07:17 AM, András Murányi wrote:
On Thu, Mar 28, 2013 at 12:42 PM, SourceForge.net noreply@sourceforge.netwrote:
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...
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?
.hc