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