<br><br><div class="gmail_quote">On Thu, Mar 28, 2013 at 9:48 PM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@at.or.at" target="_blank">hans@at.or.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 03/28/2013 07:17 AM, András Murányi wrote:<br>
> On Thu, Mar 28, 2013 at 12:42 PM, SourceForge.net<br>
> <<a href="mailto:noreply@sourceforge.net">noreply@sourceforge.net</a>>wrote:<br>
><br>
>> Patches item #3609350, was opened at 2013-03-28 04:42<br>
>> Message generated for change (Tracker Item Submitted) made by zmoelnig<br>
>> You can respond by visiting:<br>
>><br>
>> <a href="https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_id=55736" target="_blank">https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3609350&group_id=55736</a><br>
>><br>
>> Please note that this message will contain a full copy of the comment<br>
>> thread,<br>
>> including the initial issue submission, for this request,<br>
>> not just the latest update.<br>
>> Category: puredata<br>
>> Group: bugfix<br>
>> Status: Open<br>
>> Resolution: None<br>
>> Priority: 5<br>
>> Private: No<br>
>> Submitted By: IOhannes m zmölnig (zmoelnig)<br>
>> Assigned to: Miller Puckette (millerpuckette)<br>
>> Summary: prevent recursive loading of gui-plugins<br>
>><br>
>> Initial Comment:<br>
>> if a gui-plugin loads other plugin, we might easily encounter a recursion<br>
>> (where the plugin tries to load itself).<br>
>> while the current gui-plugin loader mechanism tries to prevent re-loading<br>
>> of the "same" plugin (based on the filename of the plugin), it doesn't<br>
>> catch recursive loading.<br>
>> the attached patch fixes this, by adding the to-be-loaded plugin to the<br>
>> "::loaded_plugins" list, then tries to load it and removes it from the list<br>
>> if the loading fails<br>
>> (rather than adding the plugin to the list after the loading succeeded)<br>
>><br>
>><br>
><br>
> Some minor comments from the perspective of the current plugins-plugin<br>
> which you may or may not want to consider:<br>
> - the plugin creates a ::plugins_loaded list which is almost the same as<br>
> ::loaded_plugins with the difference that "-plugin.tcl" is stripped and,<br>
> more importantly, brackets in the name are stripped too because they can<br>
> cause weird things when handling the strings in tcl.<br>
> - for the sake of tidiness, the plugin introduces a ::plugins namespace<br>
> where all the functions go.<br>
> - what about splitting the whole plugin stuff out into a new pd_plugins.tcl<br>
> so that we don't have to worry too much about bloating pd-gui.tcl?<br>
> FYI: current plugins-plugin is cca. 200 lines, of which obligatory protocol<br>
> is 20 lines, switching mechanism is 40 lines, meta extraction is 60 lines<br>
> and building the dialog box is 70 lines - thought this may assist the<br>
> decision about what to maintain inside pd and what to leave in a plugin.<br>
><br>
> My 2 cents are that the moving-the-file way of managing is ugly and a list<br>
> of enabled plugins shall be maintained in the preferences. Pd-gui could<br>
> load everything (or nothing) by default, letting a plugin modify the list.<br>
> So it would at the end take only a few extra lines in core pd gui.<br>
<br>
</div></div>Users currently install plugins by putting them in a folder. Plugins are<br>
managed via whatever preferred file management the user likes. Plugin<br>
managers can easily do the same. Then users who are used to doing it via a<br>
file browser will still be able to do that whether or not they are using a<br>
plugin manager. And installing and managing plugins both happen by moving<br>
files around.<br>
<br>
There needs to be a consistent experience here, so the management process<br>
should not be different than the installation process. I don't see any real<br>
advantage to adding complexity to installing plugins when dropping it into a<br>
folder is enough.<br>
<br>
What particular problems are there with using the DISABLED/ folder?<br>
<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><div><br>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.<br>
</div></div>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?<br>
<br clear="all">András