[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> > 2) 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.

> 
> > 3) 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