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@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@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev