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

[tcltk-perl] %replace_options question

[Vadim K. <va...@ar...>]

while implementing pTk compatibility widget "BrowseEntry" I used
%replace_options and it looks to me keys to this hash must be perlTk name
and not Tcl/Tk name, because different widgets could be implemented with a
single Tcl/Tk widget (it appears BrowseEntry cound be implemented with
ComboBox)

Should I change %replace_options logic a bit?

Vadim.

[tcltk-perl] how to extract perlTk support to separate files (modules)

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

Once we have now every type of perlTk widget to live on its own package --
(Button in Tcl::Tk::Widget::Button and so on), it will be extremely easy to
separate those into separate module and have them removed from Tk.pm file.

Say, create files
./lib/Tcl/Tk/Widget/Menu.pm
./lib/Tcl/Tk/Widget/Menubutton.pm

put proper text in there (we already have text in $Tcl::Tk::VTEMP), put
there methods (those are currently arguments to
"create_method_in_widget_package") and here it is.
Need only to replace in those subroutines $wint{$$wid} with more correct
$wid->interp

After small addition to Tcl::Tk::Widget::AUTOLOAD widget package will be
loaded on demand.

Right now, Tk.pm is small enough, and I think there's no real need to remove
something yet.
Module could grow twice its size, then we'll move out documentation to
Tcl::Tk.pod file.

However I'll move one or more Tix widgets to see how it works and to create
a sample way for other widgets to follow.
First candidate is Tix's Balloon widget.

If anyone have ideas, please let me know.

Best regards,
Vadim.

RE: [tcltk-perl] RE: scalar($w->getOpenFile)

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

> "Jeff Hobbs" <je...@Ac...> writes:
> 
> > My question is, should I create the alternate "empty" list
> > as newSV(0) (== undef), or newSVpvn("", 0) (== "" I think)?
> 
> newSVpvn("", 0) is the right choice.  Does tcl have a concept 
> similar to undef?

For the general case, no.

Jeff

Re: [tcltk-perl] RE: scalar($w->getOpenFile)

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

"Jeff Hobbs" <je...@Ac...> writes:

> My question is, should I create the alternate "empty" list
> as newSV(0) (== undef), or newSVpvn("", 0) (== "" I think)?

newSVpvn("", 0) is the right choice.  Does tcl have a concept similar
to undef?

--Gisle

[tcltk-perl] RE: scalar($w->getOpenFile)

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

>     my $mw = MainWindow->new;
>     my $label = $mw->Label(-text => "Hello")->pack;
>     if (my $file = $mw->getOpenFile) {
>         $label->configure(-text => "File [$file]");
	...
> and then hit "Cancel" to the dialog that pops up, then we 
> fill in the field with something like "File 
> [ARRAY(0x8141ad8)]".  Apparently tk_getOpenFile returns a 
> list instead of string, but this is not documented.  Since 

I have identified the source of this problem, and it has to
do with promiscuous object literal sharing in Tcl.  The
empty object (string rep "") is being converted to a list at
some point (perfectly valid, as you can still request the
string).  The problem is that when the literal "" object is
passed through to Perl, I check for tclListType first and
create an (empty) array.

My solution to this is to not create an array until the list
actually has length > 0.  This is all in SvFromTclObj, BTW.

My question is, should I create the alternate "empty" list
as newSV(0) (== undef), or newSVpvn("", 0) (== "" I think)?

BTW, the messageBox issue was the same - the literal "yes"
was being used as a boolean (which it validly is), and I was
checking for boolean type without regard to the fact that
the string rep of a boolean can be lots of things other than
0/1.  The solution there is to make sure that I only convert
booleans with no string rep to boolSVs.

Jeff

RE: [tcltk-perl] Menu changes ??

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

> > I agree that we need to improve the tests.  Below is the DialogBox 
> > code that no longer works.  This should be made a test (again, when SF 
> > comes back to life), but you can see now the issues.
> 
> I tried the code below, and it works properly.
> I mean, when I add
>   $d->Show;
> as a last line of subroutine 'add', then I see DialogBox.
> 
> It is either fixed by someone, or was not broken.

We fixed the issue already - it was related to new widget classes not being
added to ptk_w_names.

Jeff

RE: [tcltk-perl] Change the way that %-subs are handled.

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

> OK, I've manage to make this work, so the above would be
> written as:
> 
> my $sub = sub {
>     print STDERR "CALLBACK (@_)\n";
> };
> $mw->bind('<Motion>', [$sub, Tcl::EV('%X', '%Y'), '<Motion>']);

I vote for removing elder version of Ev completely and newer should be named
'Ev' to exactly match with perlTk's one. My opinion people will be less
confused it this case.
And to deal with it like following:
  $mw->bind('<Motion>', [$sub, Tcl::Ev(XY'), '<Motion>']);

In case you want to catch elder usage and warn users, it is better to warn
them when you'll detect elder 
  $int->call(\\"XY", sub{...}) 
construct.

Vadim.

Re: [tcltk-perl] tkpack tkbind needs to be removed.

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

"Konovalov, Vadim" <vko...@sp...> writes:

> I think those should not be exported in misc as well.
> :misc tag probably should also go away, both in implementation and
> documentation?

Seems good to me.

--Gisle

RE: [tcltk-perl] Menu changes ??

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

> I agree that we need to improve the tests.  Below is the
> DialogBox code that no longer works.  This should be made
> a test (again, when SF comes back to life), but you can
> see now the issues.

I tried the code below, and it works properly.
I mean, when I add
  $d->Show;
as a last line of subroutine 'add', then I see DialogBox.

It is either fixed by someone, or was not broken.

May things should work differently than I think of them?

Bets regards,
Vadim.


> use Tcl::Tk;
> 
> my $interp = new Tcl::Tk;
> my $mw = $interp->mainwindow();
> 
> my $btn = $mw->Button(-text => "Show Dialog", -command => \&add);
> $btn->pack;
> 
> sub add {
>     my $d = $mw->DialogBox(-title => "Dialog Title",
> 			   -buttons => ["Ok", "Cancel"]);
>     $d->resizable(0, 0);
> }
> 
> $interp->MainLoop();

RE: [tcltk-perl] tkpack tkbind needs to be removed.

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

> > Does anyone knows a serious reason why tkpack & tkbind must 
> not be removed?
> 
> There is also tkwait.  I don't think there is a reason, besides
> backwards compatibility with ourself.

but backward compatibility already lost, as we do not support Tcl/Tk-800,
and I think such code with 'tkwait' probably was used only in those days.
(I hope someday Tcl/Tk-800 support will be back, but this is really low
priority)

> 
> > pack and bind will work fine instead, and in case anyone 
> feels it will mess
> > with Perl's internal functions, will call them as Tcl::Tk::bind but
> > recommended way is to use $interp->bind(...).
> 
> The tkbind, tkpack and tkwait functions are exported.  Do you not want
> to export versions of these without the prefix, so they would have to
> go from the :misc export list then.

I think those should not be exported in misc as well.
:misc tag probably should also go away, both in implementation and
documentation?

Vadim.

Re: [tcltk-perl] tkpack tkbind needs to be removed.

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

"Konovalov, Vadim" <vko...@sp...> writes:

> Does anyone knows a serious reason why tkpack & tkbind must not be removed?

There is also tkwait.  I don't think there is a reason, besides
backwards compatibility with ourself.

> pack and bind will work fine instead, and in case anyone feels it will mess
> with Perl's internal functions, will call them as Tcl::Tk::bind but
> recommended way is to use $interp->bind(...).

The tkbind, tkpack and tkwait functions are exported.  Do you not want
to export versions of these without the prefix, so they would have to
go from the :misc export list then.

--Gisle

[tcltk-perl] tkpack tkbind needs to be removed.

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

Does anyone knows a serious reason why tkpack & tkbind must not be removed?
pack and bind will work fine instead, and in case anyone feels it will mess
with Perl's internal functions, will call them as Tcl::Tk::bind but
recommended way is to use $interp->bind(...).

If no-one objects, then I'll remove those.

But again, anyone with faster removal fu is welcomed :)

RE: [tcltk-perl] Re: issue building Tcl-Tk-0.77

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

> The problem isn't  tcl/tk headers, it's X headers.
	...
> I ended up with this patch:
> 
>      my ($tklibpath, $tkincpath) =
> -       process_tclconfig($tkconfig, $libspecvar, "TK_INCLUDE_SPEC");
> +       process_tclconfig($tkconfig, $libspecvar, "TK_XINCLUDES");

Ah, right you are.  That will make a difference when the X
headers aren't in a "standard" location.  I've commited the
patch.

Jeff

Re: [tcltk-perl] Re: issue building Tcl-Tk-0.77

[Mike C. <da...@gm...>]

On Wed, 21 Apr 2004 17:37:29 -0700, Jeff Hobbs <je...@ac...> wrote:
> 
> > It turns out that, indeed, now Tcl is actually linking against libtcl.
> >
> > However, Tcl-Tk is still having issues.
> >
> > Particularly, it's trying to use TK_INCLUDE_SPEC.
> >
> > However, I just unpacked every version of tk8.4.0 through
> > tk8.4.6, and NONE of them use TK_INCLUDE_SPEC.
> 
> You are correct, that var is a red herring and can be removed.
> Tcl and Tk should have their includes in the same place, so the
> TK_INCLUDE_SPEC will always be empty, but TCL_INCLUDE_SPEC will
> carry the contents regardless (and is also used).

The problem isn't  tcl/tk headers, it's X headers.

I ended up with this patch:

diff -ru Tcl-Tk-0.77.orig/Makefile.PL Tcl-Tk-0.77/Makefile.PL
--- Tcl-Tk-0.77.orig/Makefile.PL        2004-04-17 00:35:36.000000000 -0700
+++ Tcl-Tk-0.77/Makefile.PL     2004-04-21 00:01:37.000000000 -0700
@@ -61,7 +61,7 @@
     $libspecvar = "TK_LIB_SPEC";
     $libspecvar = "TK_BUILD_LIB_SPEC" if $buildspec;
     my ($tklibpath, $tkincpath) =
-       process_tclconfig($tkconfig, $libspecvar, "TK_INCLUDE_SPEC");
+       process_tclconfig($tkconfig, $libspecvar, "TK_XINCLUDES");
     $libpath .= " $tklibpath";
     $incpath .= " $tkincpath";
 } else {

RE: [tcltk-perl] Re: issue building Tcl-Tk-0.77

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

> It turns out that, indeed, now Tcl is actually linking against libtcl.
> 
> However, Tcl-Tk is still having issues.
> 
> Particularly, it's trying to use TK_INCLUDE_SPEC.
> 
> However, I just unpacked every version of tk8.4.0 through 
> tk8.4.6, and NONE of them use TK_INCLUDE_SPEC.

You are correct, that var is a red herring and can be removed.
Tcl and Tk should have their includes in the same place, so the
TK_INCLUDE_SPEC will always be empty, but TCL_INCLUDE_SPEC will
carry the contents regardless (and is also used).

> So I'm not sure if this is a bug in tk for not shipping with 
> that; or Tcl-Tk for trying to use a feature that hasn't 
> officially been shipped yet.....

Needs to be corrected in Tcl-Tk.

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

Re: [tcltk-perl] Re: issue building Tcl-Tk-0.77

[Mike C. <da...@gm...>]

On Tue, 20 Apr 2004 21:36:13 -0700, Jeff Hobbs <je...@ac...> wrote:
> Mike Castle wrote:
> > nexus@thune[9:27pm]src/Tcl-Tk/Tcl-Tk-0.77(518) perl Makefile.PL
> > perl: relocation error:
> > /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/Tcl/Tcl.so:
> > undefined symbol: Tcl_FindExecutable
> 
> It doesn't appear to be linking against the Tcl library properly.

DING DING DING
we have a winner

It turns out that, for my machine, there is no libtcl, only libtcl8.4.

But it looks like the Makefile.PL for Tcl goes to great pains to look
for libtcl only.

Ok.  So I learned about --tclconfig.

It's much happier now.

Thanks!
mrc

Re: [tcltk-perl] Re: issue building Tcl-Tk-0.77

[Mike C. <da...@gm...>]

On Tue, 20 Apr 2004 22:06:19 -0700, Mike Castle <da...@gm...> wrote:
> It turns out that, for my machine, there is no libtcl, only libtcl8.4.
> 
> But it looks like the Makefile.PL for Tcl goes to great pains to look
> for libtcl only.
> 
> Ok.  So I learned about --tclconfig.
> 
> It's much happier now.

I spoke too soon.

It turns out that, indeed, now Tcl is actually linking against libtcl.

However, Tcl-Tk is still having issues.

Particularly, it's trying to use TK_INCLUDE_SPEC.

However, I just unpacked every version of tk8.4.0 through tk8.4.6, and
NONE of them use TK_INCLUDE_SPEC.

Now this is greatly confusing as cvs shows that it's been checked in
since 2003-09-25, and bth tk8.4.5 and tk8.4.6 have been released since
then.

So I'm not sure if this is a bug in tk for not shipping with that; or
Tcl-Tk for trying to use a feature that hasn't officially been shipped
yet.....

mrc

RE: [tcltk-perl] Change the way that %-subs are handled.

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

> >$mw->bind('<Motion>', [$sub, Tcl::EV('%X', '%Y'), '<Motion>']);
> [...]
> >               You could auto-prepend each %, but I think 
> >it's good to keep the logical connection of %-sub there.
> 
> I would think the Tcl::EV name already provides the 
> connection to event variables, so I would shorten this to:
> 
>   $mw->bind('<Motion>', [$sub, Tcl::EV('XY'), '<Motion>']);
> 
> Or do you expect to ever require multi-character variable names here?

The documentation for Tcl always refers to %a, %b, etc,
but I see that Perl/Tk removes the percent and uses Ev('a').
Of course, their Ev does other things that are ... odd, and
more specifically, their docs aren't scrubbed of many other
references to %a, %b, etc in doc details.

I'm not stuck on Tcl::EV taking '%a', '%b' vs 'ab', but one
advantage is that, as you can see from the super-simple
implementation:

sub EV {
    my @events = @_;
    return bless \@events, "Tcl::EV";
}

I don't actually process the args ... which means I can use
this for other means, like:

$mw->bind('<3>', [\&mysub, Tcl::EV('[winfo class %W]', '%X', '%Y')]);

as the args are just passed right on to Tcl and are evaled
there before the callback into Perl.

So do you still think it's work "simplifying"?

Jeff

Re: [tcltk-perl] Change the way that %-subs are handled.

[Jan D. <ja...@Ac...>]

On Wed, 21 Apr 2004 11:53:37 -0700, "Jeff Hobbs" <je...@Ac...>
wrote:

>$mw->bind('<Motion>', [$sub, Tcl::EV('%X', '%Y'), '<Motion>']);

[...]

>                             You could auto-prepend each %, but
>I think it's good to keep the logical connection of %-sub there.

I would think the Tcl::EV name already provides the connection to event
variables, so I would shorten this to:

  $mw->bind('<Motion>', [$sub, Tcl::EV('XY'), '<Motion>']);

Or do you expect to ever require multi-character variable names here?

Cheers,
-Jan

RE: [tcltk-perl] Change the way that %-subs are handled.

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

>      my $sub = sub {
> 	my ($X, $Y) = (Tcl::Ev('X'), Tcl::Ev('Y'));
> 	print "X: $X Y: $Y\n";
>      };
>      $mw->bind('<Motion>', \\'XY', $sub);

OK, I've manage to make this work, so the above would be
written as:

my $sub = sub {
    print STDERR "CALLBACK (@_)\n";
};
$mw->bind('<Motion>', [$sub, Tcl::EV('%X', '%Y'), '<Motion>']);

and that would end up printing out something like:

CALLBACK (440 532 <Motion>)

I think this is a much cleaner way to operate.  It allows you
to declare the %-subs you want, like you do in Tcl, and it
passes them to your sub.  The only limitation is that the
Tcl::EV(...) must come first in the args set, although that is
just a convenience for now.  The core pieces of the code to
make this work in Tcl.pm are:

in Tcl.pm:call():
	elsif ($ref eq 'ARRAY' && ref($arg->[0]) eq 'CODE') {
	    # We have been passed something like [\&subroutine, $arg1, ...]
	    # Create a proc in Tcl that invokes this subroutine with args
	    my $events;
	    if ($#$arg >= 1 && ref($arg->[1]) eq 'Tcl::EV') {
		$events = splice(@$arg, 1, 1);
	    }
	    $args[$argcnt] =
		$interp->create_tcl_sub(sub {
		    splice @_, 0, 3; # remove ClientData, Interp and CmdName
		    $arg->[0]->(@_, @$arg[1..$#$arg]);
		}, $events);
	}

in Tcl.pm:
sub create_tcl_sub {
    my ($interp,$sub,$events,$tclname) = @_;
    unless ($tclname) {
	# stringify sub, becomes "CODE(0x######)" in ::perl namespace
	$tclname = "::perl::$sub";
    }
    unless (exists $anon_refs{$tclname}) {
	$anon_refs{$tclname}++;
	$interp->CreateCommand($tclname, $sub);
    }
    if ($events) {
	$tclname = "$tclname " . join(' ', @{$events});
    }
    return $tclname;
}
sub EV {
    my @events = @_;
    return bless \@events, "Tcl::EV";
}

and then we can get rid of all the other Ev ref stuff.  While this
might not be "ideal", I find it much more logical and easier to work
with than the previous solution.  You could auto-prepend each %, but
I think it's good to keep the logical connection of %-sub there.

Note that this also changes/corrects the call to code refs that take
args to called subroutines to pass args from Tcl first, before the
args that were given in perl.

In somewhat related changes, code and variables created in Tcl from
Perl go into the ::perl namespace in Tcl.

Jeff

[tcltk-perl] Re: scalar($w->getOpenFile)

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

"Jeff Hobbs" <je...@Ac...> writes:

> > > The thing is that there is a difference, it's just very, very subtle.  
> > > The problem is that the subtle distinctions are very important.
> > 
> > So tell me what breaks if we do it like this.
> 
> With your changes, it all remains correct, but you have to
> make those changes only to work around a bug IMO.  You cannot
> generally make the statement that all Tcl lists should be
> scalar-ized, as that will ruin performance without purpose.

I don't believe it will hurt performance, especially if you look for
void context and avoids doing any work at all in that case.  What
hurts is returning big list in scalar context.  How often does that
happen?

If it turns out to be a problem, then the next step it to return some
wrapper object in scalar context instead.  The wrapper will
automatically stringify if used as a string, but you can still use it
as a list if it is a list.  I would not go to this complexity before
it is proven that it is worth it.

--Gisle

[tcltk-perl] RE: scalar($w->getOpenFile)

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

> > The thing is that there is a difference, it's just very, very subtle.  
> > The problem is that the subtle distinctions are very important.
> 
> So tell me what breaks if we do it like this.

With your changes, it all remains correct, but you have to
make those changes only to work around a bug IMO.  You cannot
generally make the statement that all Tcl lists should be
scalar-ized, as that will ruin performance without purpose.

> > Looking into the Tk code ... I'm suspecting bug, as I see that the 
> > variable returned is specifically set to "" (empty string, not empty 
> > list) when cancel is hit.
> 
> So why was it returning a reference to an empty array then?  
> Some bug in the Tcl.pm interface code?

Haven't delved into it yet ...

> > The important thing in getOpenFile is in making sure whatever changes 
> > you do correctly handle files with spaces and multiple files (in case 
> > you pass -multiple 1 to the dialog).
> 
> If you call $mw->getOpenFile in list context it should all 
> work.  And if you provide -multiple 1 you probably know that 
> you must do that.

Yes, that is correct.  I just want to understand the bug that
we are hitting to see that it's clearly a bug, and not a subtle
difference that we have to consider.

Jeff

[tcltk-perl] Re: scalar($w->getOpenFile)

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

"Jeff Hobbs" <je...@Ac...> writes:

> > Gisle Aas <gi...@Ac...> writes:
> > 
> > > To me it wrong if:
> > >     $tcl->Eval("set var {a b c}");
> > > returns something different to perl than
> > >     $tcl->Eval("set var [list a b c]");
> > > if these two expressions have exactly the same semantics in Tcl.
> > > 
> > > I would suggest that we always return the string in scalar context and 
> > > always list in list context.  If the value is not a valid list, then 
> > > we croak in list context.
> 
> The thing is that there is a difference, it's just very, very
> subtle.  The problem is that the subtle distinctions are very
> important.

So tell me what breaks if we do it like this.

> > If you try the following program:
> > 
> >     #!/usr/bin/perl -w
> >     
> >     use Tcl::Tk qw(:perlTk);
> >     
> >     my $mw = MainWindow->new;
> >     my $label = $mw->Label(-text => "Hello")->pack;
> >     if (my $file = $mw->getOpenFile) {
> >         $label->configure(-text => "File [$file]");
> >         $mw->after(5000, sub { $mw->destroy });
> >     }
> >     
> >     MainLoop;
> > 
> > and then hit "Cancel" to the dialog that pops up, then we 
> > fill in the field with something like "File 
> > [ARRAY(0x8141ad8)]".  Apparently tk_getOpenFile returns a 
> > list instead of string, but this is not documented.  Since 
> 
> This is just a bad example.  The fact that it returns anything
> on unix is wrong wrong wrong (and possibly a bug to look into).
> On Windows, the expected "" is returned and thus you never
> enter into that loop.
> 
> Looking into the Tk code ... I'm suspecting bug, as I see that
> the variable returned is specifically set to "" (empty string,
> not empty list) when cancel is hit.

So why was it returning a reference to an empty array then?  Some bug
in the Tcl.pm interface code?

> The important thing in getOpenFile is in making sure whatever
> changes you do correctly handle files with spaces and multiple
> files (in case you pass -multiple 1 to the dialog).

If you call $mw->getOpenFile in list context it should all work.  And
if you provide -multiple 1 you probably know that you must do that.

--Gisle

[tcltk-perl] RE: scalar($w->getOpenFile)

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

> Gisle Aas <gi...@Ac...> writes:
> 
> > To me it wrong if:
> >     $tcl->Eval("set var {a b c}");
> > returns something different to perl than
> >     $tcl->Eval("set var [list a b c]");
> > if these two expressions have exactly the same semantics in Tcl.
> > 
> > I would suggest that we always return the string in scalar context and 
> > always list in list context.  If the value is not a valid list, then 
> > we croak in list context.

The thing is that there is a difference, it's just very, very
subtle.  The problem is that the subtle distinctions are very
important.

> If you try the following program:
> 
>     #!/usr/bin/perl -w
>     
>     use Tcl::Tk qw(:perlTk);
>     
>     my $mw = MainWindow->new;
>     my $label = $mw->Label(-text => "Hello")->pack;
>     if (my $file = $mw->getOpenFile) {
>         $label->configure(-text => "File [$file]");
>         $mw->after(5000, sub { $mw->destroy });
>     }
>     
>     MainLoop;
> 
> and then hit "Cancel" to the dialog that pops up, then we 
> fill in the field with something like "File 
> [ARRAY(0x8141ad8)]".  Apparently tk_getOpenFile returns a 
> list instead of string, but this is not documented.  Since 

This is just a bad example.  The fact that it returns anything
on unix is wrong wrong wrong (and possibly a bug to look into).
On Windows, the expected "" is returned and thus you never
enter into that loop.

Looking into the Tk code ... I'm suspecting bug, as I see that
the variable returned is specifically set to "" (empty string,
not empty list) when cancel is hit.

The important thing in getOpenFile is in making sure whatever
changes you do correctly handle files with spaces and multiple
files (in case you pass -multiple 1 to the dialog).

Jeff

RE: [tcltk-perl] scalar($w->getOpenFile)

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

> If you try the following program:
> 
>     #!/usr/bin/perl -w
>     
>     use Tcl::Tk qw(:perlTk);
>     
>     my $mw = MainWindow->new;
>     my $label = $mw->Label(-text => "Hello")->pack;
>     if (my $file = $mw->getOpenFile) {
>         $label->configure(-text => "File [$file]");
>         $mw->after(5000, sub { $mw->destroy });
>     }
>     
>     MainLoop;
> 
> and then hit "Cancel" to the dialog that pops up, then we fill in the
> field with something like "File [ARRAY(0x8141ad8)]".  Apparently
> tk_getOpenFile returns a list instead of string, but this is not
> documented.  Since there is no semantic difference between a list and
> a string this does not really matter to Tcl, but for perl with the
> current Tcl.pm behaviour it does.  I think we should make $tcl->Eval
> and $tcl->call behave as I describe in the quoted text above.  That
> would fix this problem and in general make things sane.
> 
> Is there a way to make an automatic test case out of this?  I guess
> I'm asking if there is a way to make the program above hit the
> "Cancel" button by itself.

I think this is not possible, as it is Modal window and this is not doable
at C level (I almost sure about on Win32).

I'll add few notes about wantarray/scalar context that needs to be fixed:

following code:

use Tcl::Tk qw/:perlTk/;
$mw = tkinit;
$t = '  te st      frfrjfr        ******    ';
$e = $mw->Entry(-textvariable=>\$t)->pack;
#$mw->Button(-text=>'test',-command=>sub{
  print "[",$e->get,"]\n";
#})->pack;
#MainLoop;

prints [testfrfrjfr******] because "$e->get" is under wantarray and we
receive a list with spaces thrown away.

Replacing to
  print "[",scalar($e->get),"]\n";
normalizes things.

That said, we must use list context only in some few functions, and mostly
call 99% of functions in scalar context.

Vadim.