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
On Fri, Jun 1, 2012 at 9:31 PM, yvan volochine yvan.pd@gmail.com 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)
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
From: András Murányi muranyia@gmail.com To: yvan volochine yvan.pd@gmail.com Cc: pd-list pd-list@iem.at 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 yvan.pd@gmail.com 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/02/2012 01:33 AM, Jonathan Wilkes wrote:
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.
[SNIP]
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.
- 1
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.
even better: spend all this time/energy to have a decent core-gui separation in pd, get rid of tcl-tk and have a neat GUI like pd deserves..
my 2 cents.. y
De: "yvan volochine" yvan.pd@gmail.com
even better: spend all this time/energy to have a decent core-gui separation in pd, get rid of tcl-tk and have a neat GUI like pd deserves..
What about using svg+javascript instead of tcl/tk?
oh, there already is some svg GUI for pd!
-- http://yvanvolochine.com http://vimeo.com/yv http://soundcloud.com/yvanvolochine
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Patrice Colet colet.patrice@free.fr To: pd-list pd-list@iem.at Cc: Sent: Saturday, June 2, 2012 12:05 AM Subject: Re: [PD] [PD-dev] Plugins preferences (Was Re: Plugins Plugin error)
De: "yvan volochine" yvan.pd@gmail.com
even better: spend all this time/energy to have a decent core-gui separation in pd, get rid of tcl-tk and have a neat GUI like pd deserves..
What about using svg+javascript instead of tcl/tk?
oh, there already is some svg GUI for pd!
How to use svg+javascript instead of tcl/tk:
- Use tcl/tk...
tk Error: line 1: illegal use of tcl/tk
-Jonathan
-- http://yvanvolochine.com http://vimeo.com/yv http://soundcloud.com/yvanvolochine
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/01/2012 11:18 PM, András Murányi wrote:
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"
domain' is the preferences folder path so I'm not sure I really follow your proposal.. why would you "hardwire" (hardcode??) it topd-extended'? ()please let
me know if I miss something)
IIRC "domain" is just the preferences folder path which differs depending on your OS.. I do agree that it has a bad name though..
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
IMHO this is a nasty preferences file design.. when you wanna remove one line in the middle, you have to change all following lines accordingly (like in .pdsettings::path)
why not just use a modern-world json|yaml config file?
y
-
András Murányi -
Jonathan Wilkes -
Patrice Colet -
yvan volochine