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, [EMAIL PROTECTED] 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 > >> [email protected] > >> http://lists.puredata.info/listinfo/pd-dev > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > 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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
