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
Yay! Its my hope that we can build upon efforts like pd-devel and desiredata. Standing on the shoulders of giants kind of thing.
I would like to contribute to a community fork that aims to be Pd compatible, but really focuses on decentralizing as much as possible, by structuring things around a very small core and everything else as libraries. I don't think we need a leader, I think we need to organize the code as a mirror of the community, which is quite decentralized.
What does this mean for working on the core? I think we need to have clear delegation of sections of the core, I think we need to have regular meetings. I think that people can head up sections that they are most interested in, and we need to figure out how to create the sections. I think that per-file is probably the easiest way. I think it is also good to start slowly and figure out to make this work. Those are some of my opinions on the matter, I hope to hear others.
Chun's and my Pd hacking experience is largely with the GUI, and it could be much better, so that's where we have been talking about starting. But really, I hope that many people get involved in areas that they are most interested in contributing.
.hc
On Dec 7, 2008, at 11:32 AM, 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
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
Yay! Its my hope that we can build upon efforts like pd-devel and desiredata. Standing on the shoulders of giants kind of thing.
I would like to contribute to a community fork that aims to be Pd compatible, but really focuses on decentralizing as much as possible, by structuring things around a very small core and everything else as libraries. I don't think we need a leader, I think we need to organize the code as a mirror of the community, which is quite decentralized.
lovely.
i think this could work very well, especially if we are able to keep what we are doing in sync with Miller's continuing work on the Pd core, making sure we merge in his changes as they come about, so that the community fork does not end up out of sync with vanilla. patches built with Pd-community should function correctly when opened with Pd-vanilla, for instance.
the more i think about this approach, the more it makes sense...
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'.
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.
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.
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
Hi all:
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'.
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 :)
thanks for your reply and letting us know what you think. We planed to make incremental changes anyway, so it should work quite well with making patches for vanilla.
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.
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.
hehe, am glad to hear that desiredata has some influence on people other then the ones involved with it;)
Are those features close to be finished? if so, we could wait a bit till then and use the new release as our starting point. Breaking down u_main.tk sounds like a good idea. Perhaps we could discuss on the possible ways to do it so we can experiment a little while the new features are being completed. what do you think?
cheers
chun
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
On 08/12/2008, at 19.33, chun@goto10.org wrote:
Breaking down u_main.tk sounds like a good idea. Perhaps we could discuss on the possible ways to do it so we can experiment a little while the new features are being completed. what do you think?
I think that would be the best first step. I also think it's ok to take some time doing so before hacking away -- and i think that was what Hans meant about by "I think it is also good to start slowly and figure out to make this work".
I don't have specific ideas for restructuring though. But hopefully you more skilled folks could start making proposal-like sketches to debate about.
This is also the part that could lead to grumpiness, so it's properly a good idea to be open-minded and make flexible suggestions.
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.
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
Works for me. The pd~ stuff looks big enough for a new release.
.hc
On Dec 10, 2008, at 1:03 PM, Miller Puckette wrote:
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
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Miller Puckette wrote:
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.
hmm, wouldn't it be even nicer to merge the separate files at runtime? just load all the files in a directory (and use ##_ prefixes (01_ .. 99_) to enforce a certain order)
i always found it somewhat awkward that we have to use "make" to "generate" a script from a script.
fmgadrs IOhannes
On Dec 23, 2008, at 12:55 AM, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
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.
hmm, wouldn't it be even nicer to merge the separate files at runtime? just load all the files in a directory (and use ##_ prefixes (01_ .. 99_) to enforce a certain order)
i always found it somewhat awkward that we have to use "make" to "generate" a script from a script.
Tcl has a mechanism for this built-in, as do most scripting langauges. In Tcl, these are called "packages". You can make Tcl packages quite easily, and then load them like any other Tcl package.
.hc
fmgadrs IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
On Dec 23, 2008, at 12:55 AM, IOhannes m zmoelnig wrote:
i always found it somewhat awkward that we have to use "make" to "generate" a script from a script.
Tcl has a mechanism for this built-in, as do most scripting langauges. In Tcl, these are called "packages". You can make Tcl packages quite easily, and then load them like any other Tcl package.
that's what i have been trying to say.
fmadrs IOhannes
oh, and merry christmas :-)
-
chun＠goto10.org -
Damian Stewart -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette -
Steffen Juul