On 5/8/2010 10:23 AM, John Cerney wrote:
> If you [Vadim] don't think the changes fit your planned direction
> for the Tcl::Tk package, I was thinking that another option for the
> changes is to be released as a separate package (something like a
> new Tcl::pTk package )
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.
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.
2) Usurp Perl/Tk. Release John's work as Tk version 805.
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.
-mjc
