[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