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

[Mathieu Bouchard]

On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote:

> 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 ?

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 ?

> 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 ?

> 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