Re: Any thoughts on the Tcl::Tk bridge?

On Jan 6, 2005, at 5:47 PM, konovalo wrote:

>
>> I did some trolling & googling around, and haven't found any concrete
>> examples of similar widgets in Tcl/Tk yet. In fact, I was a bit
>> underwhelmed at the collections of Tcl/Tk widgets I did find; 
>> hopefully,
>
>
> strangely, my impression was different.
> there are many different widget collections that are usually on SF 
> (but on other places also) - those are some of top of my head - BLT, 
> mkWidgets, Incr widgets, not speaking of some kind of standard Tix and 
> BWidgets and many more...

OK, please forgive my brashness, but it's time for me to step in. I / 
we want a standard distribution with a standard OO methodology to 
program against. Tcl has too many dis-joint collections of widgets and 
OO systems which are inconsistent and incompatible. It's a maddenning 
mess which continues to frustrate me year after year.  I've 
pushed/wished/pleaded for this for years. Tk widgets cry out for an OO 
system - one OO system - yet there is none, and no agreement can be 
reached. Simply put, I want my work to be re-usable by "the community" 
and as matters stand now it's an impossible task using Tcl/Tk.

With Perl/Tk one can create a widget in 3 lines of code that is fully 
functional: then a user can create instances of it, which have 
automatic support for cget() and configure() methods, and option 
database configuration and management. Plus, widget instance options 
*and* methods can be specified, overridden or inherited from base 
classes. There is a single, consistent, programming paradigm. It works 
well. Its really cool.

And I want to see something like it in Tcl/Tk.  Please know that I 
actually used the original Tcl::Tk code by Malcom Beattie - from it 
sprang nTk aka Perl/Tk. It worked.  It had rough edges, but so what, 
that's to be expected. I like the idea of being able to leverage the 
latest Tcl/Tk widgets and features as soon as they become available. 
But we need to be able to program outside the envelope in a simple and 
consistent manner in order to create new and better "stuff" - so the 
Tcl::Tk bridge must support that.  And it needs to be compatible with 
existing Perl/Tk code, else we wind ourselves down another road of 
complexity.

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]