> > 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. > Just my opinion from the standpoint of a developer with a lot of > existing perl/tk code to support. Regards, Vadim.
