Re: Future of Perl/Tk?

[email protected] wrote:

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

please do not consider my words as just preferring one module over other.

Let both approaches exist.

However it should be kept in mind that all other languages have Tk
bridged, and QT, and wx.


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

IMO C framework is very powerful in perl/Tk, and hardly needs many
improvements.
XS is owerwhelming in perl/Tk, its huge and high quality.

All surrounding ground needs many attention.
Lot of tiny files need updates.

Just today occasionally I saw documentation on Tk::fileevent which
refers to documentation on Tk::IO which... guess what... mentions that
in Tk4 things will improve!

Also, there are Tk->perl/Tk conversion process is automated somehow, but
this swamp needs many things to do.

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

Historically, Tkx appeared the latest, and Tcl::Tk appeared the first.
Then Tcl::Tk was forgotten for many years.

Technically, perl/Tk has most power (in code size, written books,
support etc.) and most recognition.

I can answer why another bridge when Tkx exists. Tkx is extremely small
and do not provides much convenience.
Tcl::Tk provides perl/Tk syntax to the same sort of things. Thats all
the difference.

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

I agree in all points.
perl/Tk should have central repository and continued community support.

I, personally, will hardly provide something more than occasionally
sending duct clearing patches to the developer ML, but I will very
appreciate some heart of perl/Tk where I will see on how things are
coming, and will learn for something good :):)

With best regards,
Vadim.

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