Re: Tcl::Tk Compatibility Updates for Perl/Tk

On Thu, May 13, 2010 at 2:13 AM, Konovalov, Vadim (Vadim)** CTR **
<[email protected]> wrote:
>> > I would like to echo my appreciation for John's efforts.  I
>> for one think
>> > that Tcl::Tk might be better served to just be "compatible"
>> if possible.  I
>> > do understand Vadim's point about nice clean modules, but I
>> think this one
>> > would serve the community best by reducing any possible confusion.
>> >
>> > My $.02 ..
>
> In order to get an advantage, it is often a need to pay.
> If a payment for a better compatibility would be creating a mess similar to perl/Tk, I would argue that it is not fair payment.
>
> A really thin layer is really a big advantage, IMO.
>
> In this perspective, a solution of creating yet another perl+Tcl/Tk module would be better, IMO, so it would require clean explanation on what module to select in what situation.
>
>>
>> Tcl::Tk as-is doesn't have much use to me right now, because I have a
>> large codebase of perl/tk code that I would like to use, which the
>> existing Tcl::Tk doesn't work with. (but it does work with my updates
>> to Tcl::Tk).
>
> It does perfect sence for me, but I do not want to explain here why I dislike Tkx syntax and pure-perlTk syntax of building a GUI.
>
>
>> The fact the existing Tcl::Tk is relatively small doesn't really
>> matter to me, because I have much larger set of code that I have to
>> work with. I don't think I would even notice the difference in
>> load/run times between a 1-file Tcl::Tk package and a 20-file Tcl::Tk
>> package.
>
> The point of having small Tcl::Tk also makes perfect sence for me.
> Otherwise you will just get another version of perl/Tk and will quickly fall into the same problem - random mix of Tix, Tk, image files and generated scripts of different versions.
>
> At least just pulling in many files from perl/Tk is wrong way to go.
> Pulling them slightly modified is even worse, IMHO.
>

Ok Vadim, I think you have made you views clear.

It looks like the changes I have made don't really fit into your
vision for where the Tcl::Tk package should go. It probably makes more
sense for me to release the changes as a separate package (probably
named Tcl::pTk) as I mentioned earlier. I hope you can support that.

Thanks,

John