-------------- Original message ----------------------
From: "Konovalov, Vadim Vladimirovich (Vadim)** CTR **" <vkonovalov@xxxxxxxxxx>
> 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
ptk@xxxxxxxxxxxxxxxxxx
https://mailman.stanford.edu/mailman/listinfo/ptk
|
