tcltk-perl

[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

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

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

I may make an updated release of Tix, but I don't want to
encourage the use of it.  It's a system that is showing its
age.  The very core design is just flawed in several ways.

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