> From: Michael Carman [mailto:[email protected]] > 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.
Yes, this problem is obvious. > > 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 Maybe these are implementation details what I really dislike, not the compatibility itself. Getting files from perl/Tk distro with modifications will make things unmaintainable. > corners like Tix didn't make it in. Sometimes you have to sacrifice > backward compatibility to keep moving forward. This Tix thing is a bit hard to decide on what to do. >From one side, 100% compatibility requires it, probably with some >modifications. On the other side, ordinary users just want things to "behave" on ActiveState's binaries, So, 'tix' should be included into 'tkkit.dll' - even if this is possible, it often will be not possible for ordinary users. I, for one, voting for larger "tkkit.dll", and having a way to download such a file but having more packages included will be beautiful. > > 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 Changes to Tcl/Tk.pm are perfectly possible, maybe we should start with it. Maybe this is a way to go? So we'll change the way Tcl::Tk object is (a hash instead of array), and leave it as a single file. I am not absolutely happy with this idea, but, given that it is the only real stopper, let it be so :) Then, I believe, all other compatibility files could be optionally unpacked in a nearby directory/namespace and provide better compatibility, if needed. > 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. > Yes, we'll hardly convince perl/Tk people on such a reorganization, but - if they have little plans about Tk-8.5 and further 8.6 - then may be this is also a way to go. Regards, Vadim.
