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

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