RE: Future of Perl/Tk?

 -------------- Original message ----------------------
From: "Konovalov, Vadim Vladimirovich (Vadim)** CTR **" <[email protected]>

> IMO bridging to Tcl/Tk is the best, and perl/Tk will win with including Tcl 
> interpreter.

I have to say no one stays on message quite like you do ;-) I didn't start this to debate the relative technical merits of the bridge. Personally, I would be satisfied with incremental improvements with a reasonable turn around on bug fixes. For my use, I don't particularly need to have full compatibility or access to the latest and greatest that Tcl/Tk has to offer. If I did, then I would certainly turn to Tkx and the bridge solution that it offers. 

I would be interested in seeing if I could learn something from its implementation that might be useful in improving the C framework for Perl/Tk - perhaps something that was easier to maintain without necessarily being a full bridge. Something that was a bit more compatible to existing code (though admittedly, there is some crust...) Besides, Tkx already exists, so why create another bridge?  

> 
> What a tendency is - when speaking of Tk people often speculate "Gtk is even 
> better"?

better is a fairly loaded word, which is really meaningless unless you give it some sort of context. We all have our personal preferences. For example, I tend to prefer programming with Qt than GTk, even if I'm not using Perl to do it. Lately, I've favored Wx over both. All three (and prima as well) are more verbose than Tk.
Still, they meet my needs and allow me to scratch an itch that Perl/Tk used to. 

Right now, the most attractive parts of Tcl/TK (and I suppose the bridge) to me are BLT (which I've been playing at porting), the tiles stuff, which I guess was rolled into Tcl/Tk, the Aqua support, and the active community that churns out new releases and supports it. Having said that, I'm *still* more interested in fixing Perl/Tk, as a hobby if nothing else -- even if it is only for myself ;-) Barring that, I'm more inclined to move away from Tk entirely and completely use one or more of the other toolkits I mentioned.

Still, I don't want to take anything away from the work that's been done on Tkx. I've tried it out, and it's pretty nice, Perhaps it will completely replace Perl/Tk, but I'm not particularly interested in it at the moment.

Regards,

Rob


--++**==--++**==--++**==--++**==--++**==--++**==--++**==
ptk mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/ptk