I remember you explaining this before Mathieu, and it was with great dismay that I realised DesireData was not to be an alternative to pd-gui, but a complete rewrite of the whole show.
It seems there is a necessary intermediate step by which Pd is properly separated into two truly independent GUI client and sound server code sets. >From this position, it opens the door to all kinds of alternative GUIs, so long as clear protocols are established for exchange between pd and pd-gui. On Wed, 28 Jan 2009 15:50:24 -0500 (EST) Mathieu Bouchard <ma...@artengine.ca> wrote: > On Tue, 27 Jan 2009, Hans-Christoph Steiner wrote: > > > I think there is a ton of potential to the ideas in desiredata and > > things like the new editing tricks in pd-vanilla 0.42. But they also > > have the large potential to cause harm to peoples' workflow. > > In desiredata, the workflow is almost completely backwards-compatible and > pretty much everything new is made of new keyboard shortcuts that don't > exist in pd. It should be noted that the new automagic is Miller's > innovation whereas desiredata put this feature on Ctrl+6 as a proof of > concept. > > > This is a central reason why I am involved in rewriting the GUI from > > scratch for pd-devel. I want to make Pd's GUI easy to modify and > > extend. > > The GUI is not solely u_main.tk ... even after removing t_tkcmd.c. Plenty > of C code is part of the GUI... look at most of the sys_vgui commands: > they don't let the client figure out things on its own; they make > decisions about the appearance. After all, the g_*.c files are not called > "g" for nothing: the "g" stands for graphical or gui. > > And the problem with rewriting anything from scratch is that the bigger it > is, the longer it is before you have something working properly again, and > it's even worse when there's not even a list of features that can tell you > what has to be still supported and what's just an artifact of how it's > implemented. Pd users have come to depend on the strangest of features. I > always thought that gui objects could be made opaque, but in the end, I > can't even do that without breaking someone's patches, and then, I can't > even change the priority of those gui objects: the object behind has to be > the one receiving the clicks! if I change that, it also breaks someone's > patches. This is just two examples out of 666. > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec -- Use the source _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
