[PD-dev] Plugins preferences (Was Re: [PD] Plugins Plugin error)

[Jonathan Wilkes]

>________________________________
> From: András Murányi <muranyia at gmail.com>
>To: pd-dev <pd-dev at iem.at> 
>Sent: Friday, June 1, 2012 8:55 AM
>Subject: [PD-dev] Plugins preferences (Was Re: [PD] Plugins Plugin error)
> 
>
>Hey Guys,
>
>I need some advice here.
>I figured that this method won't work - one cannot control which plugins to load *from a plugin* because some plugins may have already loaded at the time. The only method that works without modifications to the pd GUI is the "disabled" folders method.
>At the same time, I see that pd_guiprefs.tcl is more prepared for managing the recent files list than for other uses. When trying to add functionality for the plugins list, the best way seemed to be to expand the init_aqua, init_win, init_x11 functions and to create a new write_enabledplugins functions plus a read_enabledplugins in this case. This is because the "domain" has to be defined again for each new use - which seems superfluous to me because it will always be "pd-extended". (The behaviour I expected originally was this: "domain" used for something meaningful like "recentfiles" or "enabledplugins" and "key" identifying really a single key. At the moment, a key holds the content of a whole config file.)
>
>So i'm asking for your kind advice on
>A.) how plugin selection could be performed without a modification to the GUI code, or shall the functionality be added to load_startup_plugins (pd-gui.tcl:674)?

Will the plugin-plugin list itself as a plugin that can be turned on/off?  If so, that's a bad interface, because an 
accidental user action can completely destroy the convenience of your plugin-- they can't turn it back on using 
the interface.  (Taken from a different angle, 
the user cannot benefit from the convenience of your plugin in order to install it in the first place.)  If not, then 
it's not really a plugin but a core gui function and you should put it in the core gui.


>B.) should we evolve the way pd_guiprefs.tcl works in any direction?


What about augmenting/replacing guiprefs.tcl code with your interface?  Then instead of someone like 

Hans having to guess at what kinds of features might be handy to add centrally to core-pd, Pd extended 

can just ship with a bunch of gui-plugins (which the community can test at their leisure before they're 

included), and someone like Hans then only has to guess which checkbuttons to check by default.  The 

benefit is that someone like Hans doesn't have to take on responsibility for these features-- if plugin #12 

has a small bug or is sluggish/confusing, author #12 has the responsibility to fix/improve it or risk it not 

being a default-loaded plugin or-- if it's causing major issues-- not included in the next release.

I haven't looked at the code-- does pd_guiprefs.tcl have an interface for saving/reading gui prefs data?  If all 

gui-plugins can use the same interface, then adding a plugin for, say, changing default canvas/object/wire 

colors becomes really easy.


-Jonathan


>
>Thanks,
>
>András
>
>
>
>On Fri, Jun 1, 2012 at 2:09 AM, András Murányi <muranyia at gmail.com> wrote:
>
>
>>
>>
>>On Fri, May 18, 2012 at 4:55 PM, João Pais <jmmmpais at googlemail.com> wrote:
>>
>>Thanks for the report!
>>>>I've uploaded a quick bugfix to adapt to the new menu structure: there is
>>>>no Media->Preferences (or Apple->Preferences) any more, so the plugin will
>>>>appear in Media (or Apple).
>>>>
>>>>Please note that this version still uses the deprecated method of disabling
>>>>plugins by putting them in subdirectories called "disabled". This means
>>>>that new subdirectories called "disabled" will be created where file
>>>>permissions are sufficient. It will affect every user on the system.
>>>>A new version shall make use of the "::pd_guiprefs" system instead. I'll
>>>>try to give it a shot today or in the next days.
>>>>
>>>
so you mean, it pays up to wait for it, then? I'm new to 0.43, and I put the plugins in a folder in my electronic section, away from windows' standard system/user folders.
>>>
>>>João
>>>
>>Well i guess it doesn't pay up to wait anymore :)
>>The pd_guiprefs mechanism is a tiny bit less handy than I expected so this will still take some more time for me.
>>In the meantime I suggest that you get the oldstyle, but hopefully working version at http://puredata.info/downloads/plugins-plugin/releases/0.1.20120518 (of course if you can live with those extra directories).
>>
>>András
>>
>
>
>
>_______________________________________________
>Pd-dev mailing list
>Pd-dev at iem.at
>http://lists.puredata.info/listinfo/pd-dev
>
>
>