[tcltk-perl] RE: Re[4]: Tcl-Tk
Brought to you by:
hobbs
|
From: Jeff H. <je...@Ac...> - 2004-04-12 23:48:11
|
[[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
|