Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0.
That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an "infinite" undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well.
I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait.
Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility.
Cheers!
Ico
Jonathan Wilkes jancsika@yahoo.com wrote:
Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it:
If you look at the coords for a particular canvas, the 7th argument currently controls GOP status.
0 = no GOP 1 = GOP 2 = GOP + hide args
But what if this argument were thought of as controlling canvas visibility in a more general way:
-2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args
That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu.
-Jonathan
--- On Sun, 12/5/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: "Jonathan Wilkes" jancsika@yahoo.com, "Hans-Christoph Steiner" hans@at.or.at Cc: "'PD List'" pd-list@iem.at Date: Sunday, December 5, 2010, 3:33 AM Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0.
That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an "infinite" undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well.
And where does merging your changes in with pd-extended 0.43 fit into all this?
I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait.
Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility.
Cheers!
Ico
Jonathan Wilkes jancsika@yahoo.com wrote:
Hi Ivica, Since you've been rooting
around in the Pd source, I wanted to
bring up an idea about canvas properties and get your
opinion on it:
If you look at the coords for a particular canvas, the
7th argument
currently controls GOP status.
0 = no GOP 1 = GOP 2 = GOP + hide args
But what if this argument were thought of as
controlling canvas visibility in a more general way:
-2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args
That way it's not necessary to use an abstraction to
hide the menu,
plus it can be set the way it should be set-- in the
canvas
properties menu.
-Jonathan
And where does merging your changes in with pd-extended 0.43 fit into all this?
Not sure. I've submitted at least half-dozen patches into the sourceforge already and many more via mailing list and only a fraction of them have been looked at, and even less merged. Granted, some of them are somewhat controversial (e.g. revamping the scrolling algorithm), yet with such a low response rate one certainly feels discouraged in contributing further, particularly considering just how time-consuming fragmenting improvements into sub-patches can be. OTOH, I do understand just how hard it can be for one to maintain code when there are a bunch of patches trickling in at all times--it's a full-time job in and of itself, particularly in respect to regressions. Yet, having spent good two weeks chasing exactly such regressions and IMHO improving editor experience to the point where both show-stopping as well as usability bugs have been by and large squashed, I certainly hope they will find their way eventually into the core Pd. The code produced so far has been clean and (apart from fprintf's for debugging purposes that are currently commented out awaiting further potential development) should be rather easy to merge into the main trunk. The real question is whether Hans, or perhaps more importantly Miller will find doing so to be of their interest.
All that said, I think I'll continue to maintain a L2Ork variation until either its feature-set becomes synonymous with the core Pd package or there is no more reason to maintain it (and FWIW as of right now there are plenty, so I don't see me stopping the support anytime soon).
Cheers!
Ico
--- On Mon, 12/6/10, ico@vt.edu ico@vt.edu wrote:
From: ico@vt.edu ico@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, "'PD List'" pd-list@iem.at Date: Monday, December 6, 2010, 1:16 AM
And where does merging your
changes in with pd-extended 0.43 fit
into all this?
Not sure. I've submitted at least half-dozen patches into the sourceforge already and many more via mailing list and only a fraction of them have been looked at, and even less merged. Granted, some of them are somewhat controversial (e.g. revamping the scrolling algorithm), yet with such a low response rate one certainly feels discouraged in contributing further,
The argument as I understand it is that all your patches apply to 0.42-5. So pick the simplest feature or bugfix you've implemented and submit it as a patch for 0.43. If you get feedback and/or it gets merged, end of discouragement. If you don't, then the development process is broken and needs fixing.
If I knew how I'd do it myself.
-Jonathan
particularly considering just how time-consuming fragmenting improvements into sub-patches can be. OTOH, I do understand just how hard it can be for one to maintain code when there are a bunch of patches trickling in at all times--it's a full-time job in and of itself, particularly in respect to regressions. Yet, having spent good two weeks chasing exactly such regressions and IMHO improving editor experience to the point where both show-stopping as well as usability bugs have been by and large squashed, I certainly hope they will find their way eventually into the core Pd. The code produced so far has been clean and (apart from fprintf's for debugging purposes that are currently commented out awaiting further potential development) should be rather easy to merge into the main trunk. The real question is whether Hans, or perhaps more importantly Miller will find doing so to be of their interest.
All that said, I think I'll continue to maintain a L2Ork variation until either its feature-set becomes synonymous with the core Pd package or there is no more reason to maintain it (and FWIW as of right now there are plenty, so I don't see me stopping the support anytime soon).
Cheers!
Ico
The argument as I understand it is that all your patches apply to 0.42-5. So pick the simplest feature or bugfix you've implemented and submit it as a patch for 0.43. If you get feedback and/or it gets merged, end of discouragement. If you don't, then the development process is broken and needs fixing.
If I knew how I'd do it myself.
Even if I had the time to do this (meaning learn 0.43 code base), it is not that simple. I actually prefer 0.42.5 over 0.43 for several reasons:
- 0.42.5 is now rather stable while 0.43 is still evolving (AFAIK) and
as such it is IMHO not production ready. In due time this will change but AFAIK 0.43 is not there yet.
- 0.43 will likely never merge some of the UI L2Ork improvements as
they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk.
- 0.42.5 code-base is IMHO more friendly towards porting the entire
thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition.
FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd. I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward.
Just my 1-cents worth...
Ico
On 2010-12-05 21:34, Ivica Ico Bukvic wrote:
- 0.42.5 code-base is IMHO more friendly towards porting the entire
thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition.
That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest languages around) is all over the Pd code, not just in pd.tk.
Martin
On Dec 5, 2010, at 10:42 PM, Martin Peach wrote:
On 2010-12-05 21:34, Ivica Ico Bukvic wrote:
- 0.42.5 code-base is IMHO more friendly towards porting the entire
thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file. As such, I see it as a better springboard for such a transition.
That's funny. I thought the whole 0.43 thing was about putting the
tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest
languages around) is all over the Pd code, not just in pd.tk.
That's a longer term goal, but 0.43 was more limited in scope.
Basically the whole 'pd-gui' part was rewritten in only Tcl/Tk (no C),
and some changes were made on the 'pd' side to streamline those changes.
.hc
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place. In 0.42 the tcl/tk (one of the slowest languages around) is all over the Pd code, not just in pd.tk.
Martin
I guess drawing/erase commands are all over pd's code but this is easily identified and replaced with appropriate draw/select/unselect/delete commands, hence personally I don't feel this will be an issue. What will be a much greater issue is porting all the custom externals from other libs to be supported under the new toolkit (whatever that may be).
On Sun, 5 Dec 2010, Martin Peach wrote:
That's funny. I thought the whole 0.43 thing was about putting the tcl/tk into one place.
It isn't doing that at all. All the sys_vgui calls are still there. There is no such thing in 0.43.
The way it's been talked about, though, it was misleading to people who didn't look at the code difference.
tcl/tk (one of the slowest languages around)
Benchmarks indicate that Tcl/Tk 8.5 is quite faster than 8.4.
But if anyone insists on sticking with Tcl/Tk 8.4, they're sticking with year 2002 and rejecting all the speed improvements that were made between 2002 and 2007, for instance.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote:
- 0.43 will likely never merge some of the UI L2Ork improvements as
they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk.
Why do you say Tcl/Tk is «aging» ? What's the rationale for this ?
Changing toolkits is a tremendous task, and, if you ask me, it's rather hard to find something vaguely like TkCanvas. IIRC, there's nothing like it directly in Gtk and Qt. May I ask you which widget do you intend to replace TkCanvas with ???
And if you have trouble getting your diffs into pd, can you imagine the trouble of getting into pd the diffs for a change of toolkit ?
- 0.42.5 code-base is IMHO more friendly towards porting the entire
thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file.
Frankly, I don't think that this is true. Whether there is one or several files, hardly matters, though I found out I preferred one big file (but I could change my mind and it still wouldn't be a big issue).
What matters is that no matter whether you use 0.42 or 0.43, the tcl/tk stuff is NOT encapsulated in whatever way, because there's Tcl code all over the g_*.c files. I don't know how you can be hacking that code while claiming that all the tcl/tk stuff is «encapsulated». What do you mean by that ?
As such, I see it as a better springboard for such a transition.
Don't be fooled... (please)
FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd.
A big note to you : find an equivalent for TkCanvas, or how you're going to make one, before looking for anything else in there.
But another big note to you : afaict, Miller will not accept any C++ in the project.
I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward.
If Juce is any better than Tcl/Tk, the rewrite should be much easier than the original write, no ?
If it's not, then perhaps Juce is not the answer, or perhaps Tcl/Tk doesn't really suck, or perhaps the sucky part is really something else that you are not addressing. You will see.
For example, when I rewrote a lot of gui classes, I kept C and I kept Tcl/Tk, but used them in a different way than Pd does, which very radically cut down the amount of code (per gui class) by much more than half.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
- 0.43 will likely never merge some of the UI L2Ork improvements as
they are for the lack of a better word a hack, a temporary fix if you like until something better comes around to replace aging Tcl/Tk.
Why do you say Tcl/Tk is <aging> ? What's the rationale for this ?
Because its performance, appearance (at least on Linux), and buggy/incorrect documentation remind me of good ole' nineties.
Changing toolkits is a tremendous task, and, if you ask me, it's rather hard to find something vaguely like TkCanvas. IIRC, there's nothing like it directly in Gtk and Qt. May I ask you which widget do you intend to replace TkCanvas with ???
How about: Qt Canvas http://doc.trolltech.com/4.2/graphicsview-portedcanvas-canvas-cpp.html
Or better yet, how about Juce's drawable class that supports just about anything under the Sun: http://www.rawmaterialsoftware.com/api/classDrawable.html
Both of these are way faster than Tk's canvas. See the juce demo if you have a chance. On my netbook it runs circles around the Tk's editor which feels very slow. Even with l2ork improvements that cut the C<->Tk socket chatter to a fraction of what is in vanilla, it is still considerably slower than Juce doing simpler tasks.
And if you have trouble getting your diffs into pd, can you imagine the trouble of getting into pd the diffs for a change of toolkit ?
That's why I mentioned that I won't mind maintaining L2Ork iteration of Pd for as long as there is a need to do so.
- 0.42.5 code-base is IMHO more friendly towards porting the entire
thing to a different toolkit as all tcl/tk stuff is encapsulated into one (albeit ugly) big file.
Frankly, I don't think that this is true. Whether there is one or several files, hardly matters, though I found out I preferred one big file (but I could change my mind and it still wouldn't be a big issue).
What matters is that no matter whether you use 0.42 or 0.43, the tcl/tk stuff is NOT encapsulated in whatever way, because there's Tcl code all over the g_*.c files. I don't know how you can be hacking that code while claiming that all the tcl/tk stuff is <encapsulated>. What do you mean by that ?
Please check my changes and you'll see it is not that bad. Selection is already partially circumvented using tagged approach, so is moving by tag (at least for vanilla objects). So, even though there are seemingly a lot of "calls," it all pretty much boils down to draw/erase/select/move which can be easily replaced with appropriate calls once you've become comfortable with the basic code structure.
As such, I see it as a better springboard for such a transition.
Don't be fooled... (please)
I am not. Please check out the L2Ork iteration of Pd if you doubt my resolve.
FWIW, I did some digging through the Juce platform and it is rather amazing. I will dig a bit more to see how quickly one could port the core Pd.
A big note to you : find an equivalent for TkCanvas, or how you're going to make one, before looking for anything else in there.
Please check the Juce Demo that comes with Juce SDK (it builds pretty quickly) and all your concerns will be laid to rest. You may also check Max/MSP (or some of its videos) and you'll see what its canvas can or cannot do.
But another big note to you : afaict, Miller will not accept any C++ in the project.
And that is certainly his right. FWIW, I do not see changing core Pd engine in this port, but only the editor side of things, so C++ and C should still coexist quite happily. In other words C++ would replace only the Tk side of things not the core engine.
I also understand that this process will undoubtedly require a huge rewrite of all gui-based externals but sometimes one simply has to take a fews steps back to start leaping forward.
If Juce is any better than Tcl/Tk, the rewrite should be much easier than the original write, no ?
I am quite confident this is the case.
If it's not, then perhaps Juce is not the answer, or perhaps Tcl/Tk doesn't really suck, or perhaps the sucky part is really something else that you are not addressing. You will see.
For example, when I rewrote a lot of gui classes, I kept C and I kept Tcl/Tk, but used them in a different way than Pd does, which very radically cut down the amount of code (per gui class) by much more than half.
Given the complexity of Gridflow, I think you would love Juce. Have a look over its classes as well as juce demo and I think you will be pleasantly surprised.
Cheers!
Ico
-
Hans-Christoph Steiner -
ico＠vt.edu -
Ivica Ico Bukvic
-
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard