[PD-dev] pd-devel revival

Miller Puckette mpuckett at imusic1.ucsd.edu
Wed Dec 10 19:03:23 CET 2008


Maybe I should just freeze 0.42 on the sooner-than-leter side so we
can take our time on u_main questions.  Most of the stuff I'm working
on is proceeding in fits and starts anyway.

cheers
Miller

On Mon, Dec 08, 2008 at 05:49:14PM -0500, Hans-Christoph Steiner wrote:
> 
> 
> 
> 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).
> 
> .hc
> 
> 
> 
> 
> >
> > 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.
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev




More information about the Pd-dev mailing list