>________________________________ >From: András Murányi <[email protected]> >To: yvan volochine <[email protected]> >Cc: pd-list <[email protected]> >Sent: Friday, June 1, 2012 5:18 PM >Subject: Re: [PD] [PD-dev] Plugins preferences (Was Re: Plugins Plugin error) > > >On Fri, Jun 1, 2012 at 9:31 PM, yvan volochine <[email protected]> wrote: > >On 06/01/2012 09:28 PM, yvan volochine wrote: >> >>but really, instead of YA-Gui-Plugin that manages all other Gui-Plugins, >>>why not add an option in pd menu that lists and (en|dis)able plugins at >>>user's will? (which would be part of the core of pd of course) >>>now that pd ships with plugins ability, it would make much more sense >>>IMHO.. >>> >>and of course one should use pd_guiprefs to handle that.. >> >> >>y >> >> > >Thanks for the comments. Then it seems this functionality should go into main >pd-x GUI. I will try to work it out - I'll just have to make the dialog window >prettier because such an ugly window that was acceptable for the plugin cannot >go into main pd :o) Hehe. That brings up an issue, though... Basically we're talking about a "Preferences" dialogue for Pd, which Pd currently lacks for gui attributes, and also scatters in arbitrary places with the audio and midi preferences, and the thing currently called "preferences" which is just the search path dialog. What is needed is a single prefs dialog window with two frames-- 1) a listbox on the left (or treeview if you want to have categories like gui, audio, midi, etc.), and the frame on the right which has the checkboxes, labels, and buttons that correspond to the settings for whatever happens to be selected in the listbox/treeview. So if the user selects "midi setup", they see all the widgets on the right that are currently housed in the midi dialog. If they click "Plugins", they get the list of all plugins which they can turn on or off. Finally, there needs to be a common interface so that plugin #12 can create widgets for its settable attributes and they show up when the user selects "plugin #12" in the preferences dialog. That way, a canvas/box/wire color plugin can just consist of these widgets and their corresponding variables, so that the user can set them all in the "Preferences" dialog window. And if it's to be not only be a good interface for devs, but also for users, each list of attributes should have the same look and feel. I think matju did something like this with auto-generatable properties dialogs. If I get some time I'll try to code a prototype for the type of ui I'm talking about. -Jonathan > >What do you think about changing the pd_guiprefs interface in way like this: > (current -> proposed:) > domain (always "pd-extended") -> could be hardwired to "pd-extended" > key (name of the owner module, eg. "recentfiles") -> domain > (currently doesn't exist) -> key (so that you can target a single line in a >config file) > value (the content of the whole file) -> value (the value of a single key) >This change would make pd_guiprefs compatible with the .pdextended file as >well. Of course, then recentfiles.conf will look something like this: > recentfile1: /path/to/recentfile.pd > recentfile2: /path/to/another.pd > (etc.) > >András > >_______________________________________________ >[email protected] mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
