On Thu, May 13, 2010 at 2:13 AM, Konovalov, Vadim (Vadim)** CTR ** <vadim.konova...@alcatel-lucent.com> 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
