[PD-dev] pd-devel revival

Hans-Christoph Steiner hans at eds.org
Mon Dec 8 23:49:14 CET 2008

On Dec 8, 2008, at 11:11 AM, Miller Puckette wrote:

> Hi all,
> I've spent some time thinking about this.  I had only limited  
> success pulling
> code from the 0.39 "devel" because there were so many changes,  
> often with
> rationales I didn't fully understand, that I wasn't confident about my
> ability to maintain whatever I ended up with.  However, I did  
> manage to
> fold some of it back into 'vanilla'.

Yeah, I hope we learned from that experience, it ended up being a  
fast-changing fork, as far as I could tell.  I think it is important  
to keep things slow so that everyone involved can know what's going on.

> On the other hand, u_main.tk is such a mess that I don't think of  
> it in
> the same way as the rest of the Pd code at all - I'm much more  
> willing to
> take "patches" on it even if I don't understand them :)
> A couple of details.  First, I'm at work myself making a desire- 
> data-inspired
> rewrite of all the dialog windows... maybe you shouldn't lose time  
> on that
> till I have a chance to hack at it.  I'm also planning rather soon  
> to add
> a new text-editor-window feature.

Do you have a target date for this release?  I plan on working  
starting now and thru January on this.

A key reason for me wanting to do this is to clean up and structure  
u_main.tk in a rational way.  It's a mess with different people's  
coding styles, strange order, no "main()" equivalent, etc.  Plus a  
lot of the code really avoids using Tcl the way it should be used,  
and dates to Tcl 8.3.  This is be an opportunity to make clean Tcl  
code, switch to Tcl 8.5 (which has big improvements on all  
platforms), and make for an more easily extendable GUI.

So honestly, I think it makes sense to first lay down this groundwork  
before changing elements like the properties panels.  In the end, I  
think that these two parts could be developed in parallel though.

I plan on focusing on the core structure of u_main.tk then working on  
the menus, key commands, window dressing and localization support.   
Then when there is a nice structure to build upon, I really want to  
focus on making the workflow as smooth as possible, like structuring  
a lot of the ideas from DesireData.

Another thing I think is really worth exploring is replacing tkcmd.c  
with pure Tcl code.  Then the GUI would be pure Tcl and easier to  
build and manage.  Plus this should make handling charsets much  
smoother AFAIK for supporting non-ASCII chars.

> Second, and this just occurred to me, I think it would be smart to  
> separate
> the u_main.tk cide into several smaller files.  They could simply be
> concatenated by the makefile.  This way people could work on different
> parts of it with much less chance of their work colliding.  I  
> should have
> thought of this simple strategy years ago, hmm.

I am not sure that this would have a big impact, but I wouldn't  
oppose it.  Personally, I think the file should either be called  
'pd.tk' or should be broken up into Tcl 'packages' organized around  
functionality.  PortAuthority is a Tcl app that is structured like  
this (perhaps too much so, though).


> cheers
> Miller
> On Sun, Dec 07, 2008 at 05:32:59PM +0100, chun at goto10.org wrote:
>> Hi all:
>> Hope you are all well:)
>> Some of us have been toying with the idea of working on the gui code
>> (u_main.tk/pd.tk only, leaving the C code untouched) of Pd for a  
>> little
>> while now. Starting with refactoring it and gradually adds new  
>> stuff in,
>> and hopefully the changes will work its way to pd-vanilla.
>> For this reason, we would like to revive the good old pd-devel as the
>> working branch. as it would seem fitting to do so instead of  
>> making a new
>> branch with a new name.
>> So i guess this mail will act as the announcement for this new  
>> effort, as
>> well as a discussion starter for many of us who would like to talk  
>> about
>> the surrounding issues. and perhaps we could also revive the semi  
>> regular
>> dev meetings we had on #dataflow too;)
>> cheers
>> chun
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev


If you are not part of the solution, you are part of the problem.

More information about the Pd-dev mailing list