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.
András
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
On Thu, Mar 28, 2013 at 9:48 PM, Hans-Christoph Steiner hans@at.or.atwrote:
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?
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
-
András Murányi -
Hans-Christoph Steiner