Future work on Tk questions
Kenneth McDonald
references to two ongoing efforts related to tk:
1) Adding themability, to allow native look and feel on
different platforms.
2) Separating out tk from tcl, to facilitate its use by
other languages.
I think both of these ideas are just great (my interest is
in tk, not in tcl), and I was just curious if anyone can
give an update as to how they are coming, or refer me
to a home page for them.
Thanks,
Ken McDonald
Brian V. Smith
Umm, look at perl/tk, python/tk, ruby/tk, etc.
Why did you think tcl and tk were tied together?
--
Brian V. Smith (bXvs...@lbl.gov) (remove the X to send me email)
Lawrence Berkeley National Laboratory
I don't speak for LBNL - they don't pay me enough for that.
Check out the xfig site at http://epb.lbl.gov/xfig or http://www.xfig.org
David N. Welton
> Umm, look at perl/tk, python/tk, ruby/tk, etc. Why did you think
> tcl and tk were tied together?
Don't most of those require Tcl? Part of the premise of Tk is that a
decent chunk of the GUI is actually scripted. Look in /usr/lib/tck8.4
(or wherever you have tk installed) and you will see a lot of
scripts.
This is sort of a conundrum, in my opinion. It makes a lot more sense
to script things where possible, rather than hard code them in C, but
on the other hand, that buys you a dependency on a particular
scripting language...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Cameron Laird
David N. Welton <dav...@dedasys.com> wrote:
>bvs...@epb4.lbl.gov (Brian V. Smith) writes:
>
>> Umm, look at perl/tk, python/tk, ruby/tk, etc. Why did you think
>> tcl and tk were tied together?
>
>Don't most of those require Tcl? Part of the premise of Tk is that a
>decent chunk of the GUI is actually scripted. Look in /usr/lib/tck8.4
>(or wherever you have tk installed) and you will see a lot of
>scripts.
>
>This is sort of a conundrum, in my opinion. It makes a lot more sense
>to script things where possible, rather than hard code them in C, but
>on the other hand, that buys you a dependency on a particular
>scripting language...
.
.
Right. At one time, it was realistic to talk about Tk as a C-coded
GUI library, and in fact that's how Perl/Tk is implemented. It's
difficult, though, as those who regularly work with Tklib know; the
only public access to a lot of important stuff is through Tcl_Eval()
or equivalent.
One possible alternative future has, let's say, Python and Perl
people pitching in to help improve Tklib in a way that benefits
everybody. That's not happening now, though, and all the Tk gurus
from Tcl are busy with other improvements.
In fact, yet another historical trend is to *increase* Tk's
"scriptedness".
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Jeff Hobbs
Perl/Tk is the only Tk binding that I know of that doesn't use
Tcl in the bridge, and it is also the hardest to maintain. I
think it is a fallacy to assume that this is some advantage in
not having Tcl as part of that bridge, and I will be exploring
that idea more in depth soon.
Let's take for example Perl/Tk vs. Python/Tkinter (which ties
through Tcl). Perl/Tk is only recently getting up-to-date with
a unicode-enabled Tk (which has been around for years), as it
had to wait for Perl 5.8's unicode to be sufficient to be
usable internal replacement for what Tcl provided. This isn't
an issue for Tcl bridgers. Also, Perl/Tk has naught but rough
plans on getting going on OS X/Aqua, whereas Python/Tkinter
users have already figured this out by leveraging Steffen's
Tcl/Tk Aqua distribution.
Some have said the advantage to the tight binding is speed, but
I don't think that's true, it's all in the design. Many
bindings rely heavily on passing strings, but Lundh has created
a ground-up Tkinter rewrite that leverages Tcl_Obj's properly
with a notable performance improvement. There is a Tcl::Tk
module for Perl that I would like to explore to see if similar
gains can be made there.
IOW, I'm not really sure, other than for some religious zeal,
that there is a need to excise Tcl from the Tcl/Tk equation. It
provides a large base upon which Tk relies and really isn't that
heavyweight when included, in comparison to other toolkits.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Cameron Laird
Jeff Hobbs <je...@activestate.com> wrote:
.
.
.
.
.
Ooooo; I wasn't aware of Fredrik's work. Thanks for pointing
that out.
Jeff's right, in everything. At least some of the Perl/Tk
crowd and several sincere people working with other languages
sincerely believe they'll be better off without yucky Tcl
contaminating them. It's very difficult to see this belief
as anything other than bigotry. Tkinter has provided abundant
evidence that it's far, FAR easier to maintain Tcl, rather
than C, glue, even for people who don't like Tcl. Perl/Tk's
lags and lack of portability are major embarrassments.
Jeff says it all, well.
Eric Boudaillier
Kenneth McDonald wrote:
> In reading various tcl/tk articles and mailing lists, I've seen
> references to two ongoing efforts related to tk:
>
> 1) Adding themability, to allow native look and feel on
> different platforms.
>
> 2) Separating out tk from tcl, to facilitate its use by
> other languages.
>
> I think both of these ideas are just great (my interest is
> in tk, not in tcl)
[...]
I don't understand here, the main advantage of Tk over other toolkit
is Tcl. Tcl gives you simple syntax, event loop, trace variable, string
conversion, introspection...
--
-eric
Neil Madden
> .
> .
> Right. At one time, it was realistic to talk about Tk as a C-coded
> GUI library, and in fact that's how Perl/Tk is implemented. It's
> difficult, though, as those who regularly work with Tklib know; the
> only public access to a lot of important stuff is through Tcl_Eval()
> or equivalent.
>
> One possible alternative future has, let's say, Python and Perl
> people pitching in to help improve Tklib in a way that benefits
> everybody. That's not happening now, though, and all the Tk gurus
> from Tcl are busy with other improvements.
>
This is a nice idea. I'd like to think that if someone develops a
mega-widget in (say) Python, I could use it in Tcl. But how could this
work? Would Tcl have to load Python as an extension and set things up so
that everything "just worked"? The situation would then be:
Tcl -> Python -> Tcl/Tk
Where I create a Python-coded widget, which calls back into Tcl to use Tk.
I'm guessing Tkinter will create a new Tcl interpreter at this point too.
If things got really complicated, you might have an application written in
Tcl which uses a megawidget written in Ruby, which uses other megawidgets
written in Tcl, Perl and Python... At this point you have 4 interpreters
loaded and running, calling into each other at various points.
Or perhaps you just meant that the Python, Perl folks should knuckle down
and start coding some widgets and utilities in Tcl? That would probably be
the best solution (for now, at least), but unlikely to be popular.
Or perhaps, you meant "Tklib" to mean the Tk library itself, and not the Tk
equivalent of tcllib? In that case, I've probably completely missed the
target here!
Neil.
lvi...@yahoo.com
According to Kenneth McDonald <kmmcd...@wisc.edu>:
:In reading various tcl/tk articles and mailing lists, I've seen
:references to two ongoing efforts related to tk:
:
:1) Adding themability, to allow native look and feel on
:different platforms.
This work can be followed http://tcl.projectforum.com/tk/
:
:2) Separating out tk from tcl, to facilitate its use by
:other languages.
:
I don't know of any specific work going on relating to this topic.
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Peter Dalgaard
> Jeff's right, in everything. At least some of the Perl/Tk
> crowd and several sincere people working with other languages
> sincerely believe they'll be better off without yucky Tcl
> contaminating them. It's very difficult to see this belief
> as anything other than bigotry. Tkinter has provided abundant
> evidence that it's far, FAR easier to maintain Tcl, rather
> than C, glue, even for people who don't like Tcl. Perl/Tk's
> lags and lack of portability are major embarrassments.
Exactly what I ended up thinking after messing with the R-Tcl/Tk
interface. Even those aspects of Tcl that there might be some point in
criticizing (notably the shell-like macro expansions and the resulting
quoting hell) can be made to disappear (or at least nearly so) when
you use it as a glue language.
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Kenneth McDonald
Thanks for the feedback. I have no qualms about Tcl being part of the
Tcl/Tk package, my concerns were more about what sort of a performance
hit this might impose--so I'll have to take a look at Fredrik's work.
Cheers,
Ken
David N. Welton
> Thanks for the feedback. I have no qualms about Tcl being part of
> the Tcl/Tk package, my concerns were more about what sort of a
> performance hit this might impose--so I'll have to take a look at
> Fredrik's work.
For most gui work, the limiting speed factor is going to be:
1) a modern computer
or
2) the human moving the mouse and clicking a button
For those cases where speed is important, writing code in C is
probably a good idea (tktable, for instance).
Iain B. Findleton
> Kenneth McDonald <kmmcd...@wisc.edu> writes:
>
>
>>Thanks for the feedback. I have no qualms about Tcl being part of
>>the Tcl/Tk package, my concerns were more about what sort of a
>>performance hit this might impose--so I'll have to take a look at
>>Fredrik's work.
>
>
> For most gui work, the limiting speed factor is going to be:
>
> 1) a modern computer
>
> or
>
> 2) the human moving the mouse and clicking a button
>
> For those cases where speed is important, writing code in C is
> probably a good idea (tktable, for instance).
>
Its hard to imagine what a widget would be doing that would cause the
speed of a modern computer to be a factor. A global numerical weather
prediction widget perhaps?
David N. Welton
> Its hard to imagine what a widget would be doing that would cause
> the speed of a modern computer to be a factor. A global numerical
> weather prediction widget perhaps?
I *told* Jeff that Tk needed one of those...sheesh!
Seriously though... that's the sort of thing that one would normally
code in C and link into Tk/Gtk/Fltk/Qt/whatever, no?
James F. Cornwall
>
> "Iain B. Findleton" <findl...@yahoo.com> writes:
>
> > Its hard to imagine what a widget would be doing that would cause
> > the speed of a modern computer to be a factor. A global numerical
> > weather prediction widget perhaps?
>
> I *told* Jeff that Tk needed one of those...sheesh!
>
> Seriously though... that's the sort of thing that one would normally
> code in C and link into Tk/Gtk/Fltk/Qt/whatever, no?
No, you'd code it in Fortran to run on your multiprocessor teraflop
computer and send the results to your Tk/whatever... :-)
Jim C
(Fortranner & once upon a time programmer for USAF Weather facility)
>
> --
> David N. Welton
> Consulting: http://www.dedasys.com/
> Personal: http://www.dedasys.com/davidw/
> Free Software: http://www.dedasys.com/freesoftware/
> Apache Tcl: http://tcl.apache.org/
--
****************************************************
** Facilior veniam posterius quam prius capere! **
****************************************************
** James F. Cornwall, sole owner of all opinions **
** expressed in this message... **
****************************************************
Bob
<snip>
> Jeff's right, in everything. At least some of the Perl/Tk
> crowd and several sincere people working with other languages
> sincerely believe they'll be better off without yucky Tcl
> contaminating them. It's very difficult to see this belief
> as anything other than bigotry. Tkinter has provided abundant
> evidence that it's far, FAR easier to maintain Tcl, rather
> than C, glue, even for people who don't like Tcl. Perl/Tk's
> lags and lack of portability are major embarrassments.
>
> Jeff says it all, well.
I agree. I am a new user of Perl/Tk. I would rather have Perl/Tk more
up-to-date and sacrifice some "speed" then have it lag behind the Tk
implementation. If that means a tcl bridge instead of C then so be it.
The question is "how" do we change it? Is it even possible to change
it at this point?
Robert
Iain B. Findleton
> "Iain B. Findleton" <findl...@yahoo.com> writes:
>
>
>>Its hard to imagine what a widget would be doing that would cause
>>the speed of a modern computer to be a factor. A global numerical
>>weather prediction widget perhaps?
>
>
> I *told* Jeff that Tk needed one of those...sheesh!
>
> Seriously though... that's the sort of thing that one would normally
> code in C and link into Tk/Gtk/Fltk/Qt/whatever, no?
>
Well, they are typically coded in an ancient language called FORTRAN. I
have written stuff to look at the output of such a thing with Tcl
scripts, but I don't really think that one would make such a thing a
widget. Although, the laptop I use today has more power, memory, disk
and communications capacity than a Cray YMP, on which I used to run
weather codes.....
lvi...@yahoo.com
According to Bob <bo...@linuxmail.org>:
:I agree. I am a new user of Perl/Tk. I would rather have Perl/Tk more
:up-to-date and sacrifice some "speed" then have it lag behind the Tk
:implementation. If that means a tcl bridge instead of C then so be it.
:
:The question is "how" do we change it? Is it even possible to change
:it at this point?
There's nothing you need to change - just use Tcl::Tk instead of Perl::Tk ...
Robert
> According to Bob <bo...@linuxmail.org>:
> :I agree. I am a new user of Perl/Tk. I would rather have Perl/Tk more
> :up-to-date and sacrifice some "speed" then have it lag behind the Tk
> :implementation. If that means a tcl bridge instead of C then so be it.
> :
> :The question is "how" do we change it? Is it even possible to change
> :it at this point?
>
> There's nothing you need to change - just use Tcl::Tk instead of Perl::Tk ...
>
Jeff Hobbs
That's correct, but at this point the compatability with Perl/Tk is
minimal. I am working on that with Vadim, and others might contribute
later. The key point though is that in using Tcl::Tk, you have full
access to all the widgets and functionality in Tcl/Tk, and can still
do all your coding in Perl.
Robert
Can I still use the Perl/Tk syntax?
Robert
Just re-read that and answered my own question. A turtle once said "You
so rock!". :-)
Donal K. Fellows
> A global numerical weather prediction widget perhaps?
I would have found one of those *so* helpful 18 months ago... :^)
Donal.