> They currently do support 8.4 and I am planning to continue support; > Even
> 8.0 I supported > > Any signs that they don't?
>
> Not to my knowledge.
>
> One
> reason I ask though is in consideration of the possibility of merging Tcl::pTk
> and Tcl::Tk, which I have not made progress on. Even if I leave in
> compatibility with 8.4, I might only be willing to "actively support" and test
> on 8.5 or later.
Good point
However even if Tcl::Tk will drop 8.4, Tcl.pm still should support it;
OTOH for now we should elaborate a plan of "merging" of Tcl::Tk and Tcl::pTk.
In my opinion, nowadays the picture is this:
- I see lots of "good" activity on github Tcl::pTk project; I pretty much like it
- however IMO there is some, say, 5% of incompatibilities, which will never go away,
So if you take random perl/Tk program - will it just run, after you'll replace "use Tk" with "use Tcl::pTk"? mostly - no (correct me if I am wrong)
- but perlTk itself is "Tk-804.034" <-- it even mentions 8.4, which you intended to drop, so I see no very deep reason on having 100% compatibility. Syntax is good, but no more than that, 95 is enough (of course other people could have different opinion, I respect that other opinion)
Yet, there is another point:
Now Tcl::Tk is a single-file perl module, which fully allows perl-tk syntax; it is very tempting to have it single and thin and very lightweight.
For me, perl/Tk syntax is preferable (together with pure-tcl) over some perl/Tk module that I could potentially use.
To make both projects happy, I would think about following proposal:
- I will move that single file of current Tcl::Tk Tcl/Tk.pm into Tcl.pm, renamed somehow.
- ... which will be optionally called from Tcl, such as "use Tcl ':perltk';
- (while doing that I will remove lots of unneeded methods from there and will modernize it (no, this does not mean ''use warnings'' at all))
- then you could use Tcl::Tk namespace freely; merge and/or refer /or alias to each other;
IDK whether this wins something, all these thoughts are fresh;
So perl/Tk syntax will be (optionally) provided by "
tcl.pm"; no care of perl/tk compat at all.
This will mean Tcl::Tk in its current stage could leave and free space for better compatibility.
PS.
I must admit I haven't touched codebase of
tcl.pm for several months already, but surely I am planning to return to this, soon :)