tcltk-perl

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

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

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

I can agree this is not very correct way to do things...

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

Could you please explain your way of doing things?

The point here is that Tcl::Tk interpreter actually *is* plain Tcl
interpreter and may be they be'll better joined intoone single module.

OTOH having two different modules -- one is for low level communicating, and
other is for Tk part (GUI and perlTk compatibility) is very handy for me:
developing of Tcl::Tk could be done more easily and independent.

Best regards,
Vadim.

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

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

> > Could you please explain your way of doing things?
> 
> I would expect:
> 
>    $tcl = Tcl->new;
> 
> to give me an interpreter that only can do the plain Tcl stuff,
> i.e. what tclsh can do.
> 
> I would expect:
> 
>    $tcltk = Tcl::Tk->new
> 
> to be a subclass of Tcl that can do plain Tcl stuff as well as all the
> Tk stuff, ie. what wish can do.
> 
> I don't expect my $tcl to suddenly grow more capable or different just
> becase I happened to load the Tcl::Tk module in the same process
> later.  Perhaps I just misunderstand what tcl actually looks like
> underneath.  I have not used actually tcl in 15 years, so my memory of
> what it is is rusty.

All your arguments are very reasonable and in case you have patch please
give it to me.

Will you have commitment rights to CVS on SF?

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

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

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

> > > Could you please explain your way of doing things?
> > 
> > I would expect:
> > 
> >    $tcl = Tcl->new;
> > 
> > to give me an interpreter that only can do the plain Tcl stuff,
> > i.e. what tclsh can do.
> > 
> > I would expect:
> > 
> >    $tcltk = Tcl::Tk->new
> > 
> > to be a subclass of Tcl that can do plain Tcl stuff as well as all the
> > Tk stuff, ie. what wish can do.
> > 
> > I don't expect my $tcl to suddenly grow more capable or different just
> > becase I happened to load the Tcl::Tk module in the same process
> > later.  Perhaps I just misunderstand what tcl actually looks like
> > underneath.  I have not used actually tcl in 15 years, so my memory of
> > what it is is rusty.
> 
> All your arguments are very reasonable and in case you have patch please
> give it to me.

This patch make Tcl::Tk a subclass of Tcl instead of the other way
around.  The test suite certainly still passes as well as it did
before; t/optmenu.t have some failures but from its cvs log they
appear to be know.

--Gisle


Index: Tcl.pm
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
retrieving revision 1.14
diff -u -p -r1.14 Tcl.pm
--- Tcl.pm	15 Apr 2004 13:25:20 -0000	1.14
+++ Tcl.pm	16 Apr 2004 09:31:26 -0000
@@ -272,11 +272,8 @@ See http://www.perl.com/perl/misc/Artist
 
 use strict;
 use DynaLoader;
-unless (defined $Tcl::Tk::VERSION) {
-    package Tcl::Tk; # define empty package
-}
 use vars qw(@ISA);
-@ISA = qw(DynaLoader Tcl::Tk);
+@ISA = qw(DynaLoader);
 
 Tcl->bootstrap($Tcl::VERSION);
 
Index: Tcl.xs
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.xs,v
retrieving revision 1.21
diff -u -p -r1.21 Tcl.xs
--- Tcl.xs	15 Apr 2004 10:47:16 -0000	1.21
+++ Tcl.xs	16 Apr 2004 09:31:27 -0000
@@ -871,7 +871,7 @@ FETCH(av, key = NULL)
 	    croak("bad object passed to Tcl::Var::FETCH");
 	}
 	sv = *av_fetch(av, 0, FALSE);
-	if (sv_isa(sv, "Tcl")) {
+	if (sv_derived_from(sv, "Tcl")) {
 	    IV tmp = SvIV((SV *) SvRV(sv));
 	    interp = (Tcl) tmp;
 	}
@@ -904,7 +904,7 @@ STORE(av, sv1, sv2 = NULL)
 	if (AvFILL(av) != 1 && AvFILL(av) != 2)
 	    croak("bad object passed to Tcl::Var::STORE");
 	sv = *av_fetch(av, 0, FALSE);
-	if (sv_isa(sv, "Tcl")) {
+	if (sv_derived_from(sv, "Tcl")) {
 	    IV tmp = SvIV((SV *) SvRV(sv));
 	    interp = (Tcl) tmp;
 	}
Index: lib/Tcl/Tk.pm
===================================================================
RCS file: /cvsroot/tcltkce/TclTk/lib/Tcl/Tk.pm,v
retrieving revision 1.21
diff -u -p -r1.21 Tk.pm
--- lib/Tcl/Tk.pm	15 Apr 2004 22:07:31 -0000	1.21
+++ lib/Tcl/Tk.pm	16 Apr 2004 09:32:00 -0000
@@ -5,7 +5,7 @@ use Tcl;
 use Exporter;
 use DynaLoader;
 use vars qw(@ISA @EXPORT_OK %EXPORT_TAGS);
-@ISA = qw(Exporter DynaLoader);
+@ISA = qw(DynaLoader Exporter Tcl);
 
 $Tcl::Tk::VERSION = '0.77';
 
@@ -340,6 +340,7 @@ sub new {
 	$sync = 0;
     }
     $i = new Tcl;
+    bless $i, $class;
     if (!defined($tkinterp)) {
 	# CreateMainWindow is no longer necessary (was for pre-Tk8)
 	#$i->CreateMainWindow($display, $name, $sync);
@@ -371,11 +372,11 @@ sub new {
 }
 
 sub tkinit {
-    $tkinterp = new(@_);
+    $tkinterp = Tcl::Tk->new(@_);
     $mainwindow;
 }
 sub MainWindow {
-    $tkinterp = new(@_);
+    $tkinterp = Tcl::Tk->new(@_);
     $mainwindow;
 }
 

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

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

> > > I would expect:
> > > 
> > >    $tcl = Tcl->new;
> > > 
> > > to give me an interpreter that only can do the plain Tcl stuff,
> > > i.e. what tclsh can do.
> > > 
> > > I would expect:
> > > 
> > >    $tcltk = Tcl::Tk->new
> > > 
> > > to be a subclass of Tcl that can do plain Tcl stuff as 
> well as all the
> > > Tk stuff, ie. what wish can do.
> > > 
> > > I don't expect my $tcl to suddenly grow more capable or 
> different just
> > > becase I happened to load the Tcl::Tk module in the same process
> > > later.  Perhaps I just misunderstand what tcl actually looks like
> > > underneath.  I have not used actually tcl in 15 years, so 
> my memory of
> > > what it is is rusty.
> > 
> > All your arguments are very reasonable and in case you have 
> patch please
> > give it to me.
> 
> This patch make Tcl::Tk a subclass of Tcl instead of the other way
> around.  The test suite certainly still passes as well as it did
> before; t/optmenu.t have some failures but from its cvs log they
> appear to be know.

Very very nice.

t/optmenu.t has failures because test was borrowed from perlTk, and
Optionmenu there has possibility to display different string than
appropriate variable holds.
Probably this feature could be just ignored and protected from tests? Must
decide. 
Additionally, there exists in that test something like 
 $varref = $widget->cget('textvariable};
 $$varref;

So I'll add temporarily a wrapper function "wcall" to have this implemented,
later we'll improve that.
$int->wcall will call "$int->call" and will substitute result value from
%anon_refs hash.

BTW I am planning to release both modules to CPAN tomorrow or at end of
weekend.

If no one mind, I'll release both modules with version 0.77. (or is it
reasonable to make version 0.80 due to many changes and improvements that
were done?)

Best regards,
Vadim/

> 
> --Gisle
> 
> 
> Index: Tcl.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
> retrieving revision 1.14
> diff -u -p -r1.14 Tcl.pm
> --- Tcl.pm	15 Apr 2004 13:25:20 -0000	1.14
> +++ Tcl.pm	16 Apr 2004 09:31:26 -0000
> @@ -272,11 +272,8 @@ See http://www.perl.com/perl/misc/Artist
>  
>  use strict;
>  use DynaLoader;
> -unless (defined $Tcl::Tk::VERSION) {
> -    package Tcl::Tk; # define empty package
> -}
>  use vars qw(@ISA);
> -@ISA = qw(DynaLoader Tcl::Tk);
> +@ISA = qw(DynaLoader);
>  
>  Tcl->bootstrap($Tcl::VERSION);
>  
> Index: Tcl.xs
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.xs,v
> retrieving revision 1.21
> diff -u -p -r1.21 Tcl.xs
> --- Tcl.xs	15 Apr 2004 10:47:16 -0000	1.21
> +++ Tcl.xs	16 Apr 2004 09:31:27 -0000
> @@ -871,7 +871,7 @@ FETCH(av, key = NULL)
>  	    croak("bad object passed to Tcl::Var::FETCH");
>  	}
>  	sv = *av_fetch(av, 0, FALSE);
> -	if (sv_isa(sv, "Tcl")) {
> +	if (sv_derived_from(sv, "Tcl")) {
>  	    IV tmp = SvIV((SV *) SvRV(sv));
>  	    interp = (Tcl) tmp;
>  	}
> @@ -904,7 +904,7 @@ STORE(av, sv1, sv2 = NULL)
>  	if (AvFILL(av) != 1 && AvFILL(av) != 2)
>  	    croak("bad object passed to Tcl::Var::STORE");
>  	sv = *av_fetch(av, 0, FALSE);
> -	if (sv_isa(sv, "Tcl")) {
> +	if (sv_derived_from(sv, "Tcl")) {
>  	    IV tmp = SvIV((SV *) SvRV(sv));
>  	    interp = (Tcl) tmp;
>  	}
> Index: lib/Tcl/Tk.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/TclTk/lib/Tcl/Tk.pm,v
> retrieving revision 1.21
> diff -u -p -r1.21 Tk.pm
> --- lib/Tcl/Tk.pm	15 Apr 2004 22:07:31 -0000	1.21
> +++ lib/Tcl/Tk.pm	16 Apr 2004 09:32:00 -0000
> @@ -5,7 +5,7 @@ use Tcl;
>  use Exporter;
>  use DynaLoader;
>  use vars qw(@ISA @EXPORT_OK %EXPORT_TAGS);
> -@ISA = qw(Exporter DynaLoader);
> +@ISA = qw(DynaLoader Exporter Tcl);
>  
>  $Tcl::Tk::VERSION = '0.77';
>  
> @@ -340,6 +340,7 @@ sub new {
>  	$sync = 0;
>      }
>      $i = new Tcl;
> +    bless $i, $class;
>      if (!defined($tkinterp)) {
>  	# CreateMainWindow is no longer necessary (was for pre-Tk8)
>  	#$i->CreateMainWindow($display, $name, $sync);
> @@ -371,11 +372,11 @@ sub new {
>  }
>  
>  sub tkinit {
> -    $tkinterp = new(@_);
> +    $tkinterp = Tcl::Tk->new(@_);
>      $mainwindow;
>  }
>  sub MainWindow {
> -    $tkinterp = new(@_);
> +    $tkinterp = Tcl::Tk->new(@_);
>      $mainwindow;
>  }
>  
> 

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

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

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

> BTW I am planning to release both modules to CPAN tomorrow or at end of
> weekend.

Good.  I should probably hold back on changing more stuff for a while
then.

> If no one mind, I'll release both modules with version 0.77. (or is it
> reasonable to make version 0.80 due to many changes and improvements that
> were done?)

I would not jump the number, but it is all up to you.

--Gisle

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

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

> "Konovalov, Vadim" <vko...@sp...> writes:
> > If no one mind, I'll release both modules with version 0.77. (or is it 
> > reasonable to make version 0.80 due to many changes and improvements 
> > that were done?)
> 
> I would not jump the number, but it is all up to you.

Sync'ing to the same number is good, but I'm ambivalent about
jumping the number.  On the one hand, this is significantly
different than previous versions, but on the other - at the
actual API level, it's still the same (with more features).

I'd like to actually remove some of the Tcl API crap that I
think has been around for eons (all the Get|SetVar*, Append*).
These things do truly expose some Tcl C APIs (all the old
string-only ones), but to what purpose?

Maybe I'm being anal about cleaning up a few useless APIs,
but I certainly think there are more we should add (I'd like
to more efficiently tie Tcl and Perl's IO stuff together).

Jeff

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

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

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

> I'd like to actually remove some of the Tcl API crap that I
> think has been around for eons (all the Get|SetVar*, Append*).
> These things do truly expose some Tcl C APIs (all the old
> string-only ones), but to what purpose?

I agree with that.  API functions like that could also just move to
different namespace to get them out of the way.  I think it would be
valuable to actually have the Tcl namespace "empty".  All I think it
should have is a AUTOLOAD that turns all method calls into a tcl
procedure call.  I.e. that:

    $tcl->foo($a, $b)

is always the same as

    $tcl->call("foo", $a, $b)

is now.  That has the potential of simpilifying the Tk stuff I think.

For the Tcl::Tk stuff I would really like to be able to move all that
deals with perlTk compatiblity to its own module.  The API to trigger
it could be the same, but as this grows in complexity you don't want
to load it when all you need is to use the Tk interface as it is.

--Gisle

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

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

> I think it would be valuable to actually have the Tcl namespace 
> "empty".  All I think it should have is a AUTOLOAD that turns 
> all method calls into a tcl procedure call.  I.e. that:
>     $tcl->foo($a, $b)
> is always the same as
>     $tcl->call("foo", $a, $b)
> is now.  That has the potential of simpilifying the Tk stuff I think.

Yes!  This is definitely what I want out of the API.  This
is what I was expecting in some ways (more natural to me
from a Perl and Tcl point of view), I just didn't know the
magic to make it happen.

There are a few calls that we want to reserve.  We do need
to keep around a few core things (like Eval, call, etc), but
we might make a standard of how to name them.

> For the Tcl::Tk stuff I would really like to be able to move 
> all that deals with perlTk compatiblity to its own module.  
> The API to trigger it could be the same, but as this grows in 
> complexity you don't want to load it when all you need is to 
> use the Tk interface as it is.

We are all in agreement - my perl fu is just not up to the
task of doing this quickly.  I was thinking that Tcl::Tk and
Tcl::pTk should be separate modules, instead of the odd (to me)
	use Tcl::Tk q(:perlTk);
that is there now.

Jeff

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

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

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

> We are all in agreement - my perl fu is just not up to the
> task of doing this quickly.  I was thinking that Tcl::Tk and
> Tcl::pTk should be separate modules, instead of the odd (to me)
> 	use Tcl::Tk q(:perlTk);
> that is there now.

A separate module is cleaner.  I would actually prefer that, but it is
certainly an API change.  If we then end up with two ways of doing
this because we need to stay compatible I rather just keep as it is.

--Gisle

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

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

> > We are all in agreement - my perl fu is just not up to the
> > task of doing this quickly.  I was thinking that Tcl::Tk and
> > Tcl::pTk should be separate modules, instead of the odd (to me)
> > use Tcl::Tk q(:perlTk);
> > that is there now.

Actually 'use Tcl::Tk q(:perlTk);' needed only to export MainWindow,
MainLoop functions and few other, and nothing more. Most perlTk syntax is
available even without that qw(:perlTk)

Currently you still can write using "perlTk syntax":

use Tcl::Tk;
$mw = Tcl::Tk::MainWindow;
$mw->Button(-text=>'test',-command=>sub{print 'test'})->pack;
Tcl::Tk::MainLoop;


Probably things should be cleaned here as well...

>
> A separate module is cleaner.  I would actually prefer that, but it is
> certainly an API change.  If we then end up with two ways of doing
> this because we need to stay compatible I rather just keep as it is.

In case we'll move out perlTk compatibility to separate module, what will
stay in Tcl::Tk? Only few very old subroutines like "label", "toplevel" and
so on?

I think in case perlTk compatibility code will be big enough, we can arrange
to have it in nearby file and load it only when needed.

May be instead of doing special compatiiblity layer for perlTk, may be it
could be reasonable to just use perlTk syntax as main way of doing GUI in
perl? Many people just used to using that syntax from perl, and there are
books about it.

BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} =
\&Tcl::Tk::Exists;" is commented out, it is possible to debug Tcl::Tk code
ising "ptkdb" debugger, which uses perlTk.


Best regards,
Vadim.

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

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

> Actually 'use Tcl::Tk q(:perlTk);' needed only to export 
> MainWindow, MainLoop functions and few other, and nothing 
> more. Most perlTk syntax is available even without that qw(:perlTk)
> 
> Currently you still can write using "perlTk syntax":
> 
> use Tcl::Tk;
> $mw = Tcl::Tk::MainWindow; 
> $mw->Button(-text=>'test',-command=>sub{print 'test'})->pack; 
> Tcl::Tk::MainLoop;

This is in fact how we are setting our preferred Perl/Tcl::Tk
coding style, to use $mw->Widgettype as the way to create
widgets.  While it's not as "simple" as the usual Tcl style,
it is "clean" from the Perl perspective and works well.

> > A separate module is cleaner.  I would actually prefer that, but it is 
> > certainly an API change.  If we then end up with two ways of doing 
> > this because we need to stay compatible I rather just keep as it is.
> 
> In case we'll move out perlTk compatibility to separate 
> module, what will stay in Tcl::Tk? Only few very old 
> subroutines like "label", "toplevel" and so on?

There are multiple levels of compatability.  The basic coding
style, as noted above, it worth keeping.  However, there are
a lot of Perl/Tk-isms that needn't be repeated in a "clean"
Tcl::Tk, like modifications to core commands that do not
reflect the usual behavior of Tk.  There is also a ton of
extra widgets that could be moved over.

I would also like to add a "DeclareWidget" sub in Tcl::Tk
that allows the use (or some submodule) to declare that it is
making a widget available (freeing up the need to hack the
ptk2tcltk hash).  Something like:

	Tcl::Tk::Declare('BWTree',    # name in Perl
			     'tree',      # name in Tcl
			     'BWidget',   # required Tcl package
			     'Tree::use', # extra code (if necessary)
			    )

There may be other options, but you get the idea.  Perhaps
even do it in option => value syntax to extend it easier in
the future.

> May be instead of doing special compatiiblity layer for 
> perlTk, may be it could be reasonable to just use perlTk 
> syntax as main way of doing GUI in perl? Many people just 
> used to using that syntax from perl, and there are books about it.

Right, as above, but with minor mods.  I've noticed that the
Perl/Tk docs aren't accurate often enough that if we start
to veer from them, it won't be a big deal.

> BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} = 
> \&Tcl::Tk::Exists;" is commented out, it is possible to debug 
> Tcl::Tk code ising "ptkdb" debugger, which uses perlTk.

Cool, but why is that one line needed?  Are you actually
loading Perl/Tk as well?  I intentionally turn on the
tk_gestapo to avoid such interactions from occuring, as it
may lead to undesired consequences.

Jeff

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

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

> > In case we'll move out perlTk compatibility to separate
> > module, what will stay in Tcl::Tk? Only few very old
> > subroutines like "label", "toplevel" and so on?
>
> There are multiple levels of compatability.  The basic coding
> style, as noted above, it worth keeping.  However, there are
> a lot of Perl/Tk-isms that needn't be repeated in a "clean"
> Tcl::Tk, like modifications to core commands that do not
> reflect the usual behavior of Tk.  There is also a ton of
> extra widgets that could be moved over.

agreed.
And subroutine "Darken", for example, that was inserted unmodified from
perlTk, is a very first candidate to move out.


>
> I would also like to add a "DeclareWidget" sub in Tcl::Tk
> that allows the use (or some submodule) to declare that it is
> making a widget available (freeing up the need to hack the
> ptk2tcltk hash).  Something like:
>
> Tcl::Tk::Declare('BWTree',    # name in Perl
>      'tree',      # name in Tcl
>      'BWidget',   # required Tcl package
>      'Tree::use', # extra code (if necessary)
>     )

It seems to me that Tcl::Tk::Declare is similar in spirit to
create_ptk_widget_sub.
It could be renamed, its interface could be improved and so on... but
create_ptk_widget_sub actually creates widget's subroutine and used from
AUTOLOAD.

Or may be yours Tcl::Tk::Declare will be implemented using a call to
create_ptk_widget_sub?

existance of hash like %ptk2tcltk could be considered like not a hack, but
rather some kind of correct declaration of relationship (and its design
could still be improved to be, say, hash of hashes that declare properties
or something like that).

This hash allows us to create things only when needed.

Creating subroutines when required could be accomplished by standard perl's
Autoload.pm/Autosplit.pm, but I am not very like using it. It must be used
when module is large enough, and probably should be avoided otherwise (to
not complicate things)

> > May be instead of doing special compatiiblity layer for
> > perlTk, may be it could be reasonable to just use perlTk
> > syntax as main way of doing GUI in perl? Many people just
> > used to using that syntax from perl, and there are books about it.
>
> Right, as above, but with minor mods.  I've noticed that the
> Perl/Tk docs aren't accurate often enough that if we start
> to veer from them, it won't be a big deal.

Indeed.

> > BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} =
> > \&Tcl::Tk::Exists;" is commented out, it is possible to debug
> > Tcl::Tk code ising "ptkdb" debugger, which uses perlTk.
>
> Cool, but why is that one line needed?  Are you actually

I used it for trying some perlTk program, but this line really could be
deleted.

> loading Perl/Tk as well?  I intentionally turn on the
> tk_gestapo to avoid such interactions from occuring, as it
> may lead to undesired consequences.

it appears to be possible to do debugging even Tcl::Tk.pm with ptkdb, which
uses perlTk. And I did it succesfully.
I use ptkdb for quite long, and moving to console-mode debugger is not
convenient for me.

Vadim.

[tcltk-perl] Menu changes ??

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

Vadim,

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?

Thanks,

Jeff

RE: [tcltk-perl] Menu changes ??

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

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

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.

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?

Jeff

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

[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 ??

[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 ??

[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 ??

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

[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] 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
>
>
>

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

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

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

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