On Fri, 14 May 2010, Michael Carman wrote: > Please don't. There are already three ways to use Tk from Perl. Adding a > fourth is not desirable. Like it or not, Tk is competing for mindshare > with Wx, Qt, Win32::GUI, etc. Fragmenting the Tk user base would be bad. > Creating (more) confusion about which flavor of Tk bindings to use > should be avoided. > > I thought that Tcl::Tk had started as a proof-of-concept that Perl/Tk > API compatibility was possible so I'm a little surprised to hear Vadim > rejecting that idea now. Personally, I'd like to see Perl/Tk > compatibility happen, although I'd understand if some of the crustier > corners like Tix didn't make it in. Sometimes you have to sacrifice > backward compatibility to keep moving forward.
FWIW, I agree with all the points here. I too would prefer that Tcl::Tk becomes as much as possible a Perl/Tk drop-in replacement. But since Vadim disagrees, I don't think there are many options left beyond forking Tcl::Tk to another namespace. :( > Just for the sake of argument I'll throw out a couple of ideas. I'm not > sure if either is practical. > > 1) Make John's changes available as a plug-in to Tcl::Tk, > e.g. Tcl::Tk::Compat. I don't see how this is any different from John's suggestion of creating a Tcl::pTk. It also has the disadvantage of tying the new module too closely to Tcl::Tk. This will just continue to slow down the evolution of the Perl/Tk compatibility. > 2) Usurp Perl/Tk. Release John's work as Tk version 805. I don't think this would be acceptable, especially as long as there are still people willing to maintain the old Perl/Tk stuff at some level. > I'm guessing that John's work requires changes to Tcl/Tk.pm, so the > first option may not be feasible. The second option is more drastic and > would require coordination with Slaven (and whoever else is applying > patches to Tk). Given that Perl/Tk is maintenance only at this point and > John's goal is to provide the same API, it would make more sense to call > it a new version of Tk (with an all-new implementation) than to create a > parallel distribution. Unless you can provide almost universal backwards compatibility it is better to use a new namespace. At least until the package can be installed automatically from CPAN without requiring manual preparation of a local Tcl install. The obvious namespace for a new/extended/incompatible implementation for Tk would be Tkx, but that is already taken... It is not clear to me that the new name has to be under the Tcl:: namespace; a top level namespace might still be appropriate. Maybe Tk2::, similar to Apache:: and Apache2::. Cheers, -Jan
