tcltk-perl — Perl Tcl::Tk bridge module discussion

RE: [tcltk-perl] What version of perl is required?

[Konovalov, V. <vko...@sp...>]

> Apparently the code works with perl-5.6 and better, and fails with
> perl-5.005.  Is this what is expected?  I ask because I was looking
> into suggesting cleanups for the perl code, but was not sure which
> perl's you try to stay portabe to.
> 
> If perl-5.6 is the baseline, then it is a good idea to put a:
> 
>    require 5.006;

At some moment I managed things to work with 5.005_03, and, to be honest,
not very glad for 'Tcl' perl module to require 5.8.0.

5.6.1 compatibility could be approached however, but we must decide whether
elder than 5.6.0 are supported.


Could you please point out what is broken?

> statement in the Makefile.PL and Tcl.pm to document this.  Probably
> also say so in the README.

"Changes" file of Tcl distribution claims compatibility with 5.005 in 0.7

Best regards,
Vadim.

[tcltk-perl] Drop listify [PATCH]

[Gisle A. <gi...@Ac...>]

This patch seems like a good idea to me.

--Gisle


Index: Tcl.pm
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
retrieving revision 1.9
diff -u -p -u -r1.9 Tcl.pm
--- Tcl.pm	12 Apr 2004 23:09:56 -0000	1.9
+++ Tcl.pm	14 Apr 2004 09:18:45 -0000
@@ -302,28 +302,6 @@ sub LINK_READ_ONLY ()	{ 0x80 }
 
 bootstrap Tcl;
 
-# This is a crude list-creating routine.  'icall' convert perl array
-# refs into Tcl list objects efficiently, so this isn't necessary.
-# It is also not "comprehensive", so should be used as a last resort.
-sub listify {
-    my $res;
-    for my $arg (@_) {
-	my $ref = ref($arg);
-	$res .= " " if $res;
-	if (!$ref && $arg =~ / /) {
-	    $res .= "{$arg}";
-	}
-	elsif ($ref eq "ARRAY") {
-	    $res .= "{" . listify(@$arg) . "}";
-	}
-	else {
-	    $arg =~ s/\\/\\\\/g;
-	    $res .= $arg;
-	}
-    }
-    return $res;
-}
-
 #TODO make better wording here
 # %anon_refs keeps track of anonymous subroutines that were created with
 # "CreateComand" method during process of transformation of arguments for
@@ -386,12 +364,6 @@ sub call {
 		# XXX needs testing
 		$args[$argcnt] =
 		    $interp->create_tcl_sub(sub {$arg->[0]->(@$arg[1..$#$arg])});
-	    }
-	    else {
-		# Do nothing here, as icall recurses into ARRAYs and
-		# turns them into true Tcl lists
-		# Should properly turn ARRAY into Tcl list
-		#$args[$argcnt] = listify(@$arg);
 	    }
 	}
     }

[tcltk-perl] Why is Tcl a subclass of Tck::Tk?

[Gisle A. <gi...@Ac...>]

In Tcl.pm I see this code:

    unless (defined $Tcl::Tk::VERSION) {
        package Tcl::Tk; # define empty package
    }
    use vars qw(@ISA);
    @ISA = qw(DynaLoader Tcl::Tk);

Why is Tcl as subclass of Tck::Tk insted of the other way around?  The
other way seems more logical.

--Gisle

[tcltk-perl] What version of perl is required?

[Gisle A. <gi...@Ac...>]

Apparently the code works with perl-5.6 and better, and fails with
perl-5.005.  Is this what is expected?  I ask because I was looking
into suggesting cleanups for the perl code, but was not sure which
perl's you try to stay portabe to.

If perl-5.6 is the baseline, then it is a good idea to put a:

   require 5.006;

statement in the Makefile.PL and Tcl.pm to document this.  Probably
also say so in the README.

--Gisle

[tcltk-perl] Makefile.PL cleanup [PATCH]

[Gisle A. <gi...@Ac...>]

Suggested cleanup patch for Tcl's Makefile.PL. It gets rid of badly
handcoded option parsing and replace it with Getopt::Long. Similar
patch also makes sense for the Tcl-Tk one.

--Gisle

Index: Makefile.PL
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Makefile.PL,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile.PL
--- Makefile.PL	9 Apr 2004 19:05:23 -0000	1.3
+++ Makefile.PL	14 Apr 2004 08:52:43 -0000
@@ -1,33 +1,24 @@
+#!/usr/bin/perl -w
+
 # before running this script make sure you have 'tclsh' in your path, 
 # and this 'tcl' distribution is required one.
 # FreeBSD users may want to modify name of tcl interpreter (this is
 # $tclsh variable below) as long as 'tclsh' does not work in their case
 
+use strict;
+use Getopt::Long qw(GetOptions);
+
 my $tclsh = 'tclsh';
 my $tclconfig;
 my $buildspec;
 my $libpath;
 my $incpath;
 
-while (1) {
-    # Handle any --options
-    last unless @ARGV[0] =~ /^--/;
-    my $opt = shift @ARGV;
-    my $val = shift @ARGV;
-    if ($opt eq "--tclsh") {
-	$tclsh = $val;
-    }
-    elsif ($opt eq "--tclconfig") {
-	$tclconfig = $val;
-    }
-    elsif ($opt eq "--buildspec") {
-	$buildspec = 1;
-    }
-    else {
-	die "unknown option '$opt', must be --tclsh, --tclconfig or --buildspec\n";
-    }
-}
-
+GetOptions("tclsh=s", \$tclsh,
+	   "tclconfig=s", \$tclconfig,
+	   "buildspec", \$buildspec)
+    || die "Usage: perl Makefile.PL [--tclsh <path>] [--tclconfig <path>] " .
+                                   "[--buildspec] [<makemaker opts>...]\n";
 
 if ($tclconfig) {
     die "Tcl config file '$tclconfig' not found\n" unless (-f $tclconfig);

RE: [tcltk-perl] ceMakefile.pl

[Konovalov, V. <vko...@sp...>]

> The Tcl and Tcl-Tk package both come with a file called
> 'ceMakefile.pl'.  This will get installed on 'make install' as all
> *.pl are.
> 
> I suggest you rename it as 'ceMakefile.PL' or just make sure that the
> standard Makefile.PL can support WinCE.

Indeed.

Thanks, will try solving this problem at next release.

Best regards,
Vadim.

[tcltk-perl] ceMakefile.pl

[Gisle A. <gi...@Ac...>]

The Tcl and Tcl-Tk package both come with a file called
'ceMakefile.pl'.  This will get installed on 'make install' as all
*.pl are.

I suggest you rename it as 'ceMakefile.PL' or just make sure that the
standard Makefile.PL can support WinCE.

--Gisle

[tcltk-perl] few thoughts about Tcl-Tk

[Konovalov, V. <vko...@sp...>]

Dear Jeff,

1.
Right now there exist widgets (like Button, Label and so on) that when
created live in their own package, say, Tcl::Tk::Widget::Button
This will help in not interfering methods between widgets. Works better than
I expected. (I thought doing this will be more complicated than it actually
became)

However complicated widgets behave differently, say, "Menu" becomes
Tcl::Tk::Widget and not Tcl::Tk::Widget::Menu.

I am going to fix this, probably before releasing to CPAN.

Do you have additional ideas on this?

2.
It is actually not clear to me why most code in "need_tk" must present
there, and therefore much of TODO there.
I mean why I code like 
  $int->Eval("destroy [tixTree .___ptk_tree]"); #TODO
must be there.
Do you have an idea why calling $int->call("tixTree", ...) is not good
enough to find proper name? Something with TCL autoloading?
(BTW tk_optionMenu behaves same way)

3.
Is it good to create some support "tcl" or "tk" files inside Tcl-Tk just to
ease processing? Create some Tcl/Tk wrappers to move some logic from Tcl::Tk
to nearby files

4.
I think it would be very nice in addition to existing perlTk compatibility
widgets to create a while bunch of new widgets with same logic, and this
will create some more interest of using module.

Best regards,
Vadim.

[tcltk-perl] RE: Re[4]: Tcl-Tk

[Konovalov, V. <vko...@sp...>]

> [[I am switching context on this message from tcltkce-user to
>   the newly created tcltk-perl.  Drop tcltkce-user after this
>   for Perl/Tcl::Tk related discussion]].

ok

> Personally, I would restrict all my work to ActiveTcl-based
> extensions.  These are better documented / maintained, and
> you can just grab ActiveTcl for several platforms and build
> Tcl and Tcl::Tk against it without issue.

... but Tix is not one of them... BTW do you mean you will revive it (I saw
you did some CVS commits to Tix on SF)

> 
> First off, what's wrong with tk_optionMenu?  I think anything

I just didn't knew that. Thanks for pointing out, I'll remove both Tix and
itk implementations, and will try tk_optionMenu.

> that that very simple pseudo-widget doesn't handle should be
> done with a Combobox instead.  In that case, I would
> recommend more use of BWidget widgets over Tix of iwidgets.
> It's pure Tcl, thus much more portable (eg, to Win/CE).  That
> can be a disadvantage for it's Tree when you have 10,000
> elements, but for most widgets isn't an issue.

10,000 is not a number that is likely to be processed in Optionmenu in any
way.
OTOH it's hard for me to beleive Tix is able to easily process 10,000 items.
Am I wrong?

> > 3.
> > When writing test suite, a module must know whether Tix or 
> > BWidget are available and do not run test suite that has no 
> > TCL support. Besides, do you have an idea how to let people 
> > know about their TCL installation? I mean showing some kind 
> > of nice colorful table that shows available capabilities in 
> > TCL installation...
> > 
> > something like
> > 	perl -MTcl::Tk -V
> > to show configuration information...
> 
> Some of that info is in the related tcl|tkConfig.sh that I
> allow us to reference in the updated Makefile.PLs.  A lot more
> info is available dynamically with 'package names' and the like.

thanks, I'll look into this.

> 
> I think it would be rather clever to define some commands from
> Perl into the Tcl interp that allow for callbacks into perl,
> like
> 	set res [perl::eval <perl_code_here>]
> and the like.  That would allow more capable introspection in
> both directions, and allow for using consoles like tkcon to
> really shine in the Perl/Tcl::Tk environment.

This is one of my dreams... :)
It would be lovely to have such a possibility.

Best regards,
Vadim.

[tcltk-perl] RE: Re[4]: Tcl-Tk

[Jeff H. <je...@Ac...>]

[[I am switching context on this message from tcltkce-user to
  the newly created tcltk-perl.  Drop tcltkce-user after this
  for Perl/Tcl::Tk related discussion]].

> From: Eruhim Watman
> 1.
> I was playing with "Optionmenu" and implemented many options using two
> ways: Tix's OptionMenu and itk's iwidget::Optionmenu. I do 
> not know what to prefer.

Neither.  I'm trying to move away from dependence on anything
in Tix.  Although I recently completely rewrote its build
system to be more modern, the whole design just isn't that
useful anymore.  I also dislike iwidgets for its bloat, but
it is included in ActiveTcl, so is "ok" in some sense.

Personally, I would restrict all my work to ActiveTcl-based
extensions.  These are better documented / maintained, and
you can just grab ActiveTcl for several platforms and build
Tcl and Tcl::Tk against it without issue.

First off, what's wrong with tk_optionMenu?  I think anything
that that very simple pseudo-widget doesn't handle should be
done with a Combobox instead.  In that case, I would
recommend more use of BWidget widgets over Tix of iwidgets.
It's pure Tcl, thus much more portable (eg, to Win/CE).  That
can be a disadvantage for it's Tree when you have 10,000
elements, but for most widgets isn't an issue.

> 2. sub need_tk: I hope you do not mind if we'll call it 
> recursively? I mean when "Combobox" requires "BWidget" and we 
> could just call
> need_tk("BWidget") and do not add complications by checking 
> hash entry for $preloaded_tk{"BWidget"} or 
> $preloaded_tk{"Tix"} each time...

I don't mind, I just add those bits without much thought.

> 3.
> When writing test suite, a module must know whether Tix or 
> BWidget are available and do not run test suite that has no 
> TCL support. Besides, do you have an idea how to let people 
> know about their TCL installation? I mean showing some kind 
> of nice colorful table that shows available capabilities in 
> TCL installation...
> 
> something like
> 	perl -MTcl::Tk -V
> to show configuration information...

Some of that info is in the related tcl|tkConfig.sh that I
allow us to reference in the updated Makefile.PLs.  A lot more
info is available dynamically with 'package names' and the like.

I think it would be rather clever to define some commands from
Perl into the Tcl interp that allow for callbacks into perl,
like
	set res [perl::eval <perl_code_here>]
and the like.  That would allow more capable introspection in
both directions, and allow for using consoles like tkcon to
really shine in the Perl/Tcl::Tk environment.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos