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

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

[Gisle A. <gi...@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.

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.

In our private branch I have used this workaround for now:

--- Tcl-Tk/lib/Tcl/Tk.pm.~1~	Wed Apr 21 05:43:50 2004
+++ Tcl-Tk/lib/Tcl/Tk.pm	Wed Apr 21 05:43:50 2004
@@ -839,19 +839,25 @@
     my $self = shift;
     my %args = @_;
     $args{'-parent'} = $self->path unless defined $args{'-parent'};
-    $wint{$$self}->call('tk_getOpenFile', %args);
+    my @files = $wint{$$self}->call('tk_getOpenFile', %args);
+    return $files[0] unless wantarray;
+    return @files;
 }
 sub getSaveFile {
     my $self = shift;
     my %args = @_;
     $args{'-parent'} = $self->path unless defined $args{'-parent'};
-    $wint{$$self}->call('tk_getSaveFile', %args);
+    my @files = $wint{$$self}->call('tk_getSaveFile', %args);
+    return $files[0] unless wantarray;
+    return @files;
 }
 sub chooseDirectory {
     my $self = shift;
     my %args = @_;
     $args{'-parent'} = $self->path unless defined $args{'-parent'};
-    $wint{$$self}->call('tk_chooseDirectory', %args);
+    my @files = $wint{$$self}->call('tk_chooseDirectory', %args);
+    return $files[0] unless wantarray;
+    return @files;
 }
 sub messageBox {
     my $self = shift;
End of Patch.

> Alternatively we return return some object that just wraps the Tcl_Obj
> and can used as both a string and array reference.  This can be
> combined with the previous alternative, so this only happens in scalar
> context.
> 
> Alternatively we have a separate methods that indicate if a string,
> array reference or list is wanted as return value.
> 
>    $tcl->Eval_giving_string($code);
>    $tcl->Eval_giving_arrayref($code);
>    $tcl->Eval_giving_list($code);

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

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

> > I still hope that "correct" method is doable, namely
> > 
> >     $mw->bind('<Motion>', \&hadler), 
> >     sub handler {
> >       # uses %-subs freely, 
> >       print Ev('x');
> >     }
> > 
> > I thought this is quite doable with Ev to do some 
> preparations first (to
> > manage which results must be stored), and then return an 
> object that, at a
> > time when its result is needed, retreives it properly.
> 	...
> > BTW, probably right now it is the right moment to check how this is
> > implemented in Ruby or Python.
> 
> Python creates an object that tries to grab all the relevant
> %-subs.  It is flawed in that it grabs all %-subs, whether
> they are pertinent to the event type or not.  This also is
> slower than the selective %-subs model.

Indeed, grabbing all possible '%' is not best idea.
Later I'll try to see how things go in Ruby.

Now I think, may be perfect solution is not possible at all in this case...

Vadim.

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

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

Konovalov, Vadim wrote:
> I still hope that "correct" method is doable, namely
> 
>     $mw->bind('<Motion>', \&hadler), 
>     sub handler {
>       # uses %-subs freely, 
>       print Ev('x');
>     }
> 
> I thought this is quite doable with Ev to do some preparations first (to
> manage which results must be stored), and then return an object that, at a
> time when its result is needed, retreives it properly.
	...
> BTW, probably right now it is the right moment to check how this is
> implemented in Ruby or Python.

Python creates an object that tries to grab all the relevant
%-subs.  It is flawed in that it grabs all %-subs, whether
they are pertinent to the event type or not.  This also is
slower than the selective %-subs model.

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

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

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

> I finally figured out the magic that makes the commands that
> require %-substitutions to work, like so:
> 
>      my $sub = sub {
> 	my ($X, $Y) = (Tcl::Ev('X'), Tcl::Ev('Y'));
> 	print "X: $X Y: $Y\n";
>      };
>      $mw->bind('<Motion>', \\'XY', $sub);
> 
> This double-reference to the scalar seems a little weird to me.

"weirdness" is clearly stated inside Tcl.pm.
This is documented, hence is not a bug :)

But seriously I also dislike \\'XY'


> It would of course be best if we could somehow manage to get the
> substitutions as part of the command.
> 
> Now that we properly handle command callbacks with args, I would
> like to recommend this alternative:
> 
>      $mw->bind('<Motion>', [$sub, Tcl::EV('X', 'Y', ...), 
> "foo", ...]);
> 
> This would magic convert to the either the same special things
> that requires the Tcl::Ev in the sub, or perhaps (if I can make
> the magic work), have it pass the %-subs to the Tcl side of the
> callback, while maintaining the "foo", ... for the perl side.
> 
> Any objections, or better ideas?

I still hope that "correct" method is doable, namely

    $mw->bind('<Motion>', \&hadler), 
    sub handler {
      # uses %-subs freely, 
      print Ev('x');
    }

I thought this is quite doable with Ev to do some preparations first (to
manage which results must be stored), and then return an object that, at a
time when its result is needed, retreives it properly.

I remember this could lead to complications, but still I have a feeling that
is is doable.

BTW, probably right now it is the right moment to check how this is
implemented in Ruby or Python.


Vadim.

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

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

> This probably says a lot:
> 
> nexus@thune[9:37pm]src/Tcl-Tk/Tcl-Tk-0.77(520) perl -e 'use Tcl;'
> perl: relocation error:
> /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/Tc
> l/Tcl.so:
> undefined symbol: Tcl_FindExecutable

I may think of an idea when you built extension with one Tcl (entire Tcl,
not Perl module) and at execution time steps into run another version.

What version of Tcl will run if you'll just invoke it from command shell?
And can it be different from one at build time?

What will following output:
echo 'puts $tcl_version' | tclsh

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

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

I finally figured out the magic that makes the commands that
require %-substitutions to work, like so:

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

This double-reference to the scalar seems a little weird to me.
It would of course be best if we could somehow manage to get the
substitutions as part of the command.

Now that we properly handle command callbacks with args, I would
like to recommend this alternative:

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

This would magic convert to the either the same special things
that requires the Tcl::Ev in the sub, or perhaps (if I can make
the magic work), have it pass the %-subs to the Tcl side of the
callback, while maintaining the "foo", ... for the perl side.

Any objections, or better ideas?

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

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

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

Mike Castle wrote:

> Just realize what I sent you before was probably the output from my
> build script.

> 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.

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

Re: [tcltk-perl] recent changelog changes...

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

Vadim Konovalov wrote:

> looking at recent changelog changes people could think we have time travel
> device :)

Yes, with you so far ahead of UTC, that's life.  It would be nice
if the ChangeLog stuck to UTC, but I don't think it's a big deal. :)

Jeff

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

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

This probably says a lot:

nexus@thune[9:37pm]src/Tcl-Tk/Tcl-Tk-0.77(520) perl -e 'use Tcl;'
perl: relocation error:
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/Tcl/Tcl.so:
undefined symbol: Tcl_FindExecutable

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

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

On Wed, 21 Apr 2004 08:24:48 +0400, Vadim Konovalov <va...@ar...> wrote:
> 
> > Please note:  I probably don't actually use the modules described in
> > this email.  I'm just trying to go through all of the modules on CPAN,
> > install them, and report issues back to the maintainers.  Just my way
> > of trying to give back to the Perl community.
> >
> > I just installed Tcl-0.77 and when trying this:
> >
> > Extracting /usr/mirror/cpan/modules/by-module/Devel/Tcl-Tk-0.77.tar.gz...
> > perl: relocation error:
> /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/Tcl/Tcl.so:
> undefined symbol: Tcl_FindExecutable
> >
> > Any thoughts?
> 
> thank you, we'll try to reproduce and fix this problem. Could you please say
> version numbers for Perl and Tcl?
> 
> Right now, I'll ask others: does anyone has experienced similar problem?

perl-5.8.4-RC2
Tcl-0.77
Tcl-Tk-0.77

Just realize what I sent you before was probably the output from my
build script.

This might be more recognizable:

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

[tcltk-perl] recent changelog changes...

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

looking at recent changelog changes people could think we have time travel
device :)

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

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

> Please note:  I probably don't actually use the modules described in
> this email.  I'm just trying to go through all of the modules on CPAN,
> install them, and report issues back to the maintainers.  Just my way
> of trying to give back to the Perl community.
>
> I just installed Tcl-0.77 and when trying this:
>
> Extracting /usr/mirror/cpan/modules/by-module/Devel/Tcl-Tk-0.77.tar.gz...
> perl: relocation error:
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi/auto/Tcl/Tcl.so:
undefined symbol: Tcl_FindExecutable
>
> Any thoughts?

thank you, we'll try to reproduce and fix this problem. Could you please say
version numbers for Perl and Tcl?

Right now, I'll ask others: does anyone has experienced similar problem?

Best regards,
Vadim.

[tcltk-perl] create_widget_package questions ...

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

Okay, I'm done doing today changes (including Menu/Menubutton fixes with
t/ptk-compat.t).
I hope I did not interfere much with someone else.

My today's changes are not perfect but I hope following will be much better.

Best regards,
Vadim.

Re: [tcltk-perl] create_widget_package questions ...

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

...yet $::VTEMP should be at least renamed as $::Tcl::Tk::VTEMP or better
yet just used as HERE-doc style.

Re: [tcltk-perl] create_widget_package questions ...

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

> > Once you'll insert DialogBox entry into %ptk2tcktk hash, all
> > its methods will be autoloaded as usual, because of
> >
> >     $method =~
> > s/^(Tcl::Tk::Widget::((MainWindow|$ptk_w_names)::)?)//o or
> > die "weird inheritance ($method)";
> >
> > .... and DialogBox will be stripped out, because it will be
> > inside $ptk_w_names string.
>
> I see ... so the create_widget_package should be completed
> to add the info into %ptk2tcltk and update $ptk_w_names?

Indeed, you're right. I forgot to populate dynamically that hash, but I was
used to think about it as some constant hash that could not be changed.

And must not forget to remove that tranling "o" in s///o operator.

But, after you said all that, probably AUTOLOAD should just analyze method
slightly differently: remove leading Tcl::Tk::Widget, then see if it has
/^(\w+)::/ after that, and then see how to process remaining method.

OTOH MultipleWidget could be used as alternate way... sometimes simplier
way, I think...

BTW, once you're at this, it could be reasonable to invent a way to
communicate with widgets like blt::graph, widgets that in Tcl have package
specifier... (But this is way unnecessary right now)

RE: [tcltk-perl] create_widget_package questions ...

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

> Once you'll insert DialogBox entry into %ptk2tcktk hash, all 
> its methods will be autoloaded as usual, because of
> 
>     $method =~ 
> s/^(Tcl::Tk::Widget::((MainWindow|$ptk_w_names)::)?)//o or 
> die "weird inheritance ($method)";
> 
> .... and DialogBox will be stripped out, because it will be 
> inside $ptk_w_names string.

I see ... so the create_widget_package should be completed
to add the info into %ptk2tcltk and update $ptk_w_names?

Jeff

Re: [tcltk-perl] create_widget_package questions ...

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

Once you'll insert DialogBox entry into %ptk2tcktk hash, all its methods
will be autoloaded as usual, because of

    $method =~ s/^(Tcl::Tk::Widget::((MainWindow|$ptk_w_names)::)?)//o or
die "weird inheritance ($method)";

.... and DialogBox will be stripped out, because it will be inside
$ptk_w_names string.

----- Original Message -----
From: "Jeff Hobbs" <je...@ac...>
To: "'Vadim Konovalov'" <va...@ar...>
Cc: <tcl...@li...>; "'Jan Dubois'"
<Ja...@ac...>
Sent: Wednesday, April 21, 2004 12:39 AM
Subject: [tcltk-perl] create_widget_package questions ...


> Vadim,
>
> I have a few questions about create_widget_package design, or
> rather one question with multiple facets.
>
> The AUTOLOAD stuff basically all points to Tcl::Tk::Widget::AUTOLOAD
> as the autoloader of choice.
>
> The problem I am having with "method inheritance" changes is as
> follows ...
>
> A DialogBox is really a Toplevel with extra methods.  As you
> noted, all the special stuff used to be created in the same
> Tcl::Tk::Widget package, which isn't really desirable.  I like
> that the creation of the first DialogBox creates
> Tcl::Tk::Widget::DialogBox and creates the special methods as
> subs of that package.
>
> The problem comes when I run something like the DialogBox
> sample I sent earlier, where 'resizable' must be autoloaded.
> Since a DialogBox used to be a Tcl::Tk::Widget object, we
> would AUTOLOAD with $method eq "resizable", and it would be
> found in ptk2tcltk_wm.  Now however $method eq
> "DialogBox::resizable", and it isn't found.
>
> It seems that we can't blindly strip to the base method name
> in all cases, but we do for some.
>
> Do you have any good ideas at how to handle this change in
> behavior?
>
> Thanks,
>
> Jeff
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl
>
>
>

[tcltk-perl] create_widget_package questions ...

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

Vadim,

I have a few questions about create_widget_package design, or
rather one question with multiple facets.

The AUTOLOAD stuff basically all points to Tcl::Tk::Widget::AUTOLOAD
as the autoloader of choice.

The problem I am having with "method inheritance" changes is as
follows ...

A DialogBox is really a Toplevel with extra methods.  As you
noted, all the special stuff used to be created in the same
Tcl::Tk::Widget package, which isn't really desirable.  I like
that the creation of the first DialogBox creates
Tcl::Tk::Widget::DialogBox and creates the special methods as
subs of that package.

The problem comes when I run something like the DialogBox
sample I sent earlier, where 'resizable' must be autoloaded.
Since a DialogBox used to be a Tcl::Tk::Widget object, we
would AUTOLOAD with $method eq "resizable", and it would be
found in ptk2tcltk_wm.  Now however $method eq
"DialogBox::resizable", and it isn't found.

It seems that we can't blindly strip to the base method name
in all cases, but we do for some.

Do you have any good ideas at how to handle this change in
behavior?

Thanks,

Jeff

Re: [tcltk-perl] Menu changes ??

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

> I found the issue.  In the change from special_widget_abilities
> to the create_method_in_widget_package, you changed the command
> from something like:
>
>    checkbutton => sub {
>        $int->call("$$mnu",'add','checkbutton',@_);
>    },
>
> to
>
> checkbutton => sub {
>     my $wid = shift;
>     my $int = $wint{$$wid};
>     $int->call("$$mnu",'add','checkbutton',@_);
> },
>
> but the change in $mnu context requires this instead:
>
> checkbutton => sub {
>     my $wid = shift;
>     my $int = $wint{$$wid};
>     $int->call($wid->path,'add','checkbutton',@_);
> },
>
> That correction has the menus working as before.  So we have to
> just watch for this in related shifts.

You're right.

Actually when subroutine gets variable from outer scope -- this is always
non-obvious trickery. When this subroutine gets a value of variable of outer
scope, and when reference to it? (AFAIU latter is happened)
Yet such subroutines could not live independently in a package. A logic
dictates to move from "widget-related" subroutines (special abilities) to
just package methods. Not only resources economy (each such widget will have
its own subroutine to process ability) but yet when we'll start moving some
widget methods to outer place, it will be much easier to code methods
package-wide, not object-wide.

I hope I'll be in time fixing Menu/Menubutton today...

Vadim.

RE: [tcltk-perl] Menu changes ??

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

> > > I see you are working on menus ... the AUTOLOAD problem you
> 
> I was not working on menus, I just tried to move menu to its 
> own package.

I found the issue.  In the change from special_widget_abilities
to the create_method_in_widget_package, you changed the command
from something like:

   	checkbutton => sub {
   	    $int->call("$$mnu",'add','checkbutton',@_);
   	},

to

	checkbutton => sub {
	    my $wid = shift;
	    my $int = $wint{$$wid};
	    $int->call("$$mnu",'add','checkbutton',@_);
	},

but the change in $mnu context requires this instead:

	checkbutton => sub {
	    my $wid = shift;
	    my $int = $wint{$$wid};
	    $int->call($wid->path,'add','checkbutton',@_);
	},

That correction has the menus working as before.  So we have to
just watch for this in related shifts.

Jeff

RE: [tcltk-perl] Menu changes ??

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

> > it is because of bug in _addcascade subroutine: it creates 
> submenu but 
> > it creates items not in it but rather in upper menu. This was from 
> > very beginning and I did not changed that.
> 
> here it is:

Vadim,

This change doesn't affect the fact that all menus are
being created in the toplevel.  Right now I can't connect
to SF, so I can't see if you are referring to that change
in conjunction with other fixes.

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.

Thanks,

Jeff

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();
exit;

Re: [tcltk-perl] Menu changes ??

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

> it is because of bug in _addcascade subroutine: it creates submenu but it
> creates items not in it but rather in upper menu. This was from very
> beginning and I did not changed that.

here it is:

sub _addcascade {
    my $mnu = shift;
    my $mnup = $mnu->path;
    my $int = $wint{$mnup};
    my $smnu = $mnu->Menu; # return unique widget id
    my %args = @_;
    my $tearoff = delete $args{'-tearoff'};
    if (defined($tearoff)) {
        $smnu->configure(-tearoff => $tearoff);
    }
    $args{'-menu'} = $smnu;
    my $mis = delete $args{'-menuitems'};
    _process_menuitems($int,$smnu,$mis); # but there was
_process_menuitems($int,$mnu,$mis); and hence wrong cascade...

Re: [tcltk-perl] Menu changes ??

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

Did some analyzis and now see what has happened.

> > I see you are working on menus ... the AUTOLOAD problem you

I was not working on menus, I just tried to move menu to its own package.

> > just fixed, but now I see my menus created flat across the
> > entire first level (instead of as submenus).  Can you explain

it is because of bug in _addcascade subroutine: it creates submenu but it
creates items not in it but rather in upper menu. This was from very
beginning and I did not changed that.

Im now fixing this, and wrote some probe in t/ subdir.

Please see CVS update that is to follow...

> For example, DialogBox used to get "resizable" from the
> AUTOLOAD that handled Toplevels.  Now I get an error that
> that isn't a recognized method.  Are only the created
> methods in a widget package then recognized?  This makes
> it to hard to make renamed/megawidgets.  Is there an easy
> way to correct inheritance while maintaining the
> separation you were trying to achieve?

if something is not moving smoothly -- just leave it in Tcl::Tk::Widget
package for now, i.e. do not bless it to its own package. But in this case
"special_widget_abilities".

But mostly we must populate test suite with a stuff that is broking from
time to time...

Vadim.

RE: [tcltk-perl] Menu changes ??

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

> > > I see you are working on menus ... the AUTOLOAD problem you 
> > > just fixed, but now I see my menus created flat across the 
> > > entire first level (instead of as submenus).  Can you explain 
> > > what you are trying to do with that area?
> 
> Must mention 'Menu' in %ptk2tcltk hash, but I saw you already 
> got the idea
> :) (I see you fixed that)

Me wrong, it was me who added that line and I worgot that I comitted change
....
http://cvs.sourceforge.net/viewcvs.py/tcltkce/TclTk/lib/Tcl/Tk.pm?r1=1.31&r2
=1.32

About submenus -- I'll fix that today evening.

Best regards,
Vaidm.

RE: [tcltk-perl] Menu changes ??

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

> > I see you are working on menus ... the AUTOLOAD problem you 
> > just fixed, but now I see my menus created flat across the 
> > entire first level (instead of as submenus).  Can you explain 
> > what you are trying to do with that area?

Must mention 'Menu' in %ptk2tcltk hash, but I saw you already got the idea
:) (I see you fixed that)
Also I prepared a patch that also fixes "Multiplewidget" error.
this one:
@@ -1905,7 +1908,7 @@
                 ($p, $prepl) = ($1,$2);
             }
             else {$prepl = $p}
-            if ($j+1<=$#a) {
+            if ($j+1<=$#a && ref($a[$j+1])) {
                 $prepl = $a[$j+1];
                 splice @a, $j+1, 1;
             }


> 
> Along the same lines, I'm not sure that the way that
> create_widget_package and create_method_in_widget_package
> are "correct".  They have different method inheritance
> behavior as the previous Tk.pm.

But it was much worse:
previously, for example Button, created all its submethods in a package
Tcl::Tk::Widget::Button
Similar to Label and some other 'standard' widgets.

All widgets that have their predeclared creation method lived in package
Tcl::Tk::Widget
And method with same names will intermix.



> 
> For example, DialogBox used to get "resizable" from the
> AUTOLOAD that handled Toplevels.  Now I get an error that
> that isn't a recognized method.  Are only the created
> methods in a widget package then recognized?  This makes
> it to hard to make renamed/megawidgets.  Is there an easy
> way to correct inheritance while maintaining the
> separation you were trying to achieve?

I hope this is quite doable...
I'll see tomorrow eveing.

Yet it is obvious to have test suite for creation all required widgets.
(DialogBox must be included at the very first place).

Will do at next weekend and make another release to CPAN.

But anyone with faster test creation fu is welcomed here :)

Best regards,
Vadim.