segmented and curvy cords comes with another patching design, like in maxMSP where almost all the time the messages order doesn't have an importance.
Also it's said by some users that max patches works better when everything is in the same subpatch, and that is not the case with pd.
Many other has explained, certainly better than me, why not using those cords in list archive.
Also, the project of designing other interfaces for pd is really seducting, and there is already some projects that allow the use of another GUI, like
the J. Sarlo's Graphical Interface Editing Tool and Run-time Environment (cpu glouton) or T. Grill's python wrapper and tkinter. (require python knowledge) or HC's [sys_gui] (require tcl knowledge, and very slow response) or [mixed/toxy/tot] (unstable, require tcl knowledge) and xi widgets that require tcl/tk 8.5, a working [widget] external, and half a dozen of tk libs.
There are also other projects using pd sources with another GUI design like desiredata
----- Mail Original ----- De: "Lorenzo" lsutton@libero.it À: pd-list@iem.at Envoyé: Vendredi 16 Avril 2010 12h07:08 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [PD] puredata_gui_design
András Murányi wrote:
One (hard) aspect of GUI design in case of Pd is that the GUI widgets are provided by Tcl/Tk at the moment, which does not allow for such kind of skinning, afaik. There has been talk, however, about migrating to another GUI toolkit. Really? Which one?
As a comment on the designs which graphically look very cool... this will probably be unpopular... but I *wouldn't* second segmented or curvy chords (like in some other popular dataflow programs) as I think they tend to make patches (and one's coding) less clear and in the end a bit "messy".. but it may be me, as I do tend to become messy and like something which constraints me not to :)
Lorenzo
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list