Hey all,
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-devel/0.41...
If you haven't followed the SVN check-ins, Chun and I have been working on rewriting the Tcl side of things. Things are structured into some Tcl packages, but I am not sure they are named or organized correctly just yet, so feedback would be good. Also, Tcl's syntax can get obfuscated fast, so I am trying to keep things pretty easy to read for non-Tcl programmers.
The exciting news (for me at least) is that I have a working Tcl implementation of the network side of the GUI, replacing t_tkcmd.c, t_tk.h, and t_main.c. It is now using Tcl's catch{} on incoming commands so that invalid Tcl commands, like typing a '{' in current Pd, can be handled cleanly.
If anyone is ready to join in, there are many things that people could work on:
- internationalization using msgcat and standard .po files
- unified preference panel with tabs (like standard pref panes on GNOME, Mac OS X, and Windows)
- flexible key binding code so that people can easily experiment with all these ideas (this is started in pd_bindings.tcl)
- restructure Pd window for cleaner UI and code
- canvas scrollbar logic
and more....
.hc
This is a follow up to the other mail on pd-list regarding the same. I think it makes sense to carry on on pd-dev, hence i just respond to this email.
On Wed, January 7, 2009 1:14 am, Hans-Christoph Steiner wrote:
If anyone is ready to join in, there are many things that people could work on:
internationalization using msgcat and standard .po files
unified preference panel with tabs (like standard pref panes on
GNOME, Mac OS X, and Windows)
- flexible key binding code so that people can easily experiment with
all these ideas (this is started in pd_bindings.tcl)
restructure Pd window for cleaner UI and code
canvas scrollbar logic
and more....
Most of that is what i think is new features (more then it is restructuring). So that explains the confusion.
Let me ask: How easy will it be to merge this work into (vanilla) pd-0.42-x? - I was thinking that if there was done a restructure (my definition) then adding the new (gui) features of 0.42-x into that wouldn't be that much work. But adding them and merging new features within the restructure might be in my head/imagination.
My concern is that i hope for these things to end up in vanilla, hence i was thinking that restructuring and getting up to speed with vanilla would help with that. Given the restructure was accepted by Miller it would then also be much easier for him to take or not take changes. And as a bonus also easier for anyone to take or not take changes (ala distribution idea behind f.x. Git).
I hope this doesn't seam like ranting. It is intended as an honest and constructive input.
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
Best, Steffen (trying to navigate to the pref panel code)
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
since 0.42 is just out, shouldn't all work be based on that?
afaict, most changes in pd.tk from 0.41 to 0.42 seem to be pretty trivial. once i am able to get pd-devel running (i haven't re-tried yet), i would volunteer to incorporate these changes
@ miller: afaics the data driven dialogs (ddd) are only in a concept stage, they are not used anywhere yet. is this correct? if so, i would just ignore them for now :-)
@ pd-devel-team: iirc, the idea of pd-devel so far was to not tuch any c-code but only the tcl/tk side of things. how true is this? (i noticed quite a lot of affected C-files; i really hope this will not make the attempts of pd-devel void (i thought the deal was making pd-gui.tk usable should not force miller to accept changes on the C-side)
fgamsdr IOhannes
Well, I'm using the ddd stuff in an extern I haven't released. My intent has been to rewrite all the Pd dialogs using ddd once it was stable. But now that other folks are working on the tk code I'll just wait to see what they propose.
I'm split between the idea of incorporating pd.tk changes piecemeal or as a lump. If the latter, it would be important not to make too many changes to the pd/tk interface...
cheers Miller
On Tue, Jan 13, 2009 at 09:39:13AM +0100, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
since 0.42 is just out, shouldn't all work be based on that?
afaict, most changes in pd.tk from 0.41 to 0.42 seem to be pretty trivial. once i am able to get pd-devel running (i haven't re-tried yet), i would volunteer to incorporate these changes
@ miller: afaics the data driven dialogs (ddd) are only in a concept stage, they are not used anywhere yet. is this correct? if so, i would just ignore them for now :-)
@ pd-devel-team: iirc, the idea of pd-devel so far was to not tuch any c-code but only the tcl/tk side of things. how true is this? (i noticed quite a lot of affected C-files; i really hope this will not make the attempts of pd-devel void (i thought the deal was making pd-gui.tk usable should not force miller to accept changes on the C-side)
fgamsdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The pd/tk interface doesn't need to change, at least so far it hasn't. That is one thing I have been working to keep completely intact. One thing that will have to change is s_inter.c since it handles the startup procedure. Mostly, I think it'll be drastically simplified as most of the #ifdefs can be removed.
So far the C changes have been (diff attached):
- deleted t_tk.h, t_tkcmd.c, t_main.c - removed #include "t_tk.h" from the iemguis (g_*.c) (unneeded in any version) - changed pdgui start line in s_inter to work on GNU/Linux
All that said, if you want to take this code Miller, then as a lump is really the only way. Just taking bits would be missing the bulk of the improvements. Or would be close to another rewrite in the amount of work, in my estimation.
.hc
On Jan 13, 2009, at 10:30 AM, Miller Puckette wrote:
Well, I'm using the ddd stuff in an extern I haven't released. My intent has been to rewrite all the Pd dialogs using ddd once it was stable. But now that other folks are working on the tk code I'll just wait to see what they propose.
I'm split between the idea of incorporating pd.tk changes piecemeal or as a lump. If the latter, it would be important not to make too many changes to the pd/tk interface...
cheers Miller
On Tue, Jan 13, 2009 at 09:39:13AM +0100, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
since 0.42 is just out, shouldn't all work be based on that?
afaict, most changes in pd.tk from 0.41 to 0.42 seem to be pretty trivial. once i am able to get pd-devel running (i haven't re-tried yet), i would volunteer to incorporate these changes
@ miller: afaics the data driven dialogs (ddd) are only in a concept stage, they are not used anywhere yet. is this correct? if so, i would just ignore them for now :-)
@ pd-devel-team: iirc, the idea of pd-devel so far was to not tuch any c-code but only the tcl/tk side of things. how true is this? (i noticed quite a lot of affected C-files; i really hope this will not make the attempts of pd-devel void (i thought the deal was making pd-gui.tk usable should not force miller to accept changes on the C-side)
fgamsdr IOhannes
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
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
On Jan 13, 2009, at 3:39 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Steffen Juul wrote:
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
since 0.42 is just out, shouldn't all work be based on that?
afaict, most changes in pd.tk from 0.41 to 0.42 seem to be pretty trivial. once i am able to get pd-devel running (i haven't re-tried yet), i would volunteer to incorporate these changes
Honestly, I would like to wait until the dust settles on 0.42. If there aren't major changes to u_main.tk in 0.42 and right now we aren't changing the C side, then I don't think there is any rush.
.hc
@ miller: afaics the data driven dialogs (ddd) are only in a concept stage, they are not used anywhere yet. is this correct? if so, i would just ignore them for now :-)
@ pd-devel-team: iirc, the idea of pd-devel so far was to not tuch any c-code but only the tcl/tk side of things. how true is this? (i noticed quite a lot of affected C-files; i really hope this will not make the attempts of pd-devel void (i thought the deal was making pd-gui.tk usable should not force miller to accept changes on the C-side)
fgamsdr IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
kill your television
On Jan 7, 2009, at 4:59 AM, Steffen Juul wrote:
This is a follow up to the other mail on pd-list regarding the same. I think it makes sense to carry on on pd-dev, hence i just respond to this email.
On Wed, January 7, 2009 1:14 am, Hans-Christoph Steiner wrote:
If anyone is ready to join in, there are many things that people could work on:
internationalization using msgcat and standard .po files
unified preference panel with tabs (like standard pref panes on
GNOME, Mac OS X, and Windows)
- flexible key binding code so that people can easily experiment with
all these ideas (this is started in pd_bindings.tcl)
restructure Pd window for cleaner UI and code
canvas scrollbar logic
and more....
Most of that is what i think is new features (more then it is restructuring). So that explains the confusion.
Let me ask: How easy will it be to merge this work into (vanilla) pd-0.42-x?
- I was thinking that if there was done a restructure (my
definition) then adding the new (gui) features of 0.42-x into that wouldn't be that much work. But adding them and merging new features within the restructure might be in my head/imagination.
My concern is that i hope for these things to end up in vanilla, hence i was thinking that restructuring and getting up to speed with vanilla would help with that. Given the restructure was accepted by Miller it would then also be much easier for him to take or not take changes. And as a bonus also easier for anyone to take or not take changes (ala distribution idea behind f.x. Git).
I hope this doesn't seam like ranting. It is intended as an honest and constructive input.
That aside. Just making sure: This devel branch is branching of vanilla 0.41-4 and the only focus is the gui (as opposed to also merging devel-0.39 features)?
Best, Steffen (trying to navigate to the pref panel code)
Since I know the 0.41.4 code, that's where I started, but yes, the goal is to write something that Miller would accept. I'll check out the 0.42 code for relevant changes once I get a chance. So I am hoping for feedback from Miller and this list so that is likely to happen. We discussed this at LAC2008, and I am going on what Miller said then, which is that it would make the most sense to rewrite things, then Miller would take the whole file.
That said, I think getting more participation from other devs would also help this goal. Right now things are structured as I have been coding, but more contributions will only improve the organization and code.
I think we should start having some dev meetings about this on #dataflow. I'll happily also do audio/video conferencing for those like me who like higher bandwidth communication. Chun mentioned going out of town, so perhaps we should wait for him to come back. My schedule is pretty flexible at the moment, how about a dev meeting this weekend?
.hc