practical limits of Tcl/Tk?

2 views
Skip to first unread message

Russ Paielli

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to

I am absolutely convinced that Tcl/Tk is the greatest thing since sliced
bread for many applications. However, I am just a bit confused about its
practical limitations. For what type of graphical applications is it
better to give up on Tcl and use Java or C/C++/Motif?

For example, here at NASA Ames we do lots of work on decision support
tools for air traffic controllers. These tools involve full-screen map
displays showing the positions of the aircraft in a region, with several
windows that can be brought up to set configuration parameters, detect
and resolve potential conflicts, and perform many other functions.
These run on a network of Sun Workstations and are typically programmed
in C with Motif.

Some of this software will eventually be redesigned and rewritten in
object-oriented C++. Will I make a fool of myself if I propose that the
graphical part of it (or at least some of the graphical part of it) be
written in Tcl?

--

Russ Paielli

mailto:rpai...@mail.arc.nasa.gov
http://www.geocities.com/CapeCanaveral/Lab/9488


Cameron Laird

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
In article <3713D945...@mail.arc.nasa.gov>,
.
.
.
It's very, very likely that you will be mocked. A
fair number of your peers will find the thought of
Tk competing with C++-bound Motif risible.

They're wrong.

If this were a green-field project, I'd wholeheartedly
recommend Tk. Is your team truly writing raw Motif?
You're not using any higher-order GUI toolkit? They
should love Tk ...

As you know, Tcl is a great technology for all kinds
of configuration tasks.

The biggest liability of Tk in this general domain
is simply that it doesn't have a well-established
widget set beyond the core. If your programmers can
put up with Motif, though, that can hardly be a problem.

People who are good at C++ and bad with Tcl can make
ugly messes when they try to define new widgets and
classes. That's largely a cultural decision.

Ames ... 'bet you can get some experienced nearby out-
siders to visit you and proselytize.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

Scott Redman

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
I've been told by someone (D. Richard Hipp?) that an experiment was done
with Tk vs. Motif and found that Tk had much higher performance, especially
over a network connection. Motif has a habit of requesting lots of stuff
from the X Server while drawing to the display. Remotely, it's a dog.

You can write drawing code in C to implement parts of the display
(if Tk can't handle something or is too slow). JPL does this for some
of their internal stuff (can't remember which group, but it had
something to do with Asteroid tracking). Tk can display many different
graphics formats, and there are many extensions to add even more.

I'd probably use Tk for the GUI for a C or C++ application for the reasons
above. If you're targeting NT and UNIX, then definitely. If you're daring
and want to try MFC, MainWin (from MainSoft, www.mainsoft.com) can provide
it on UNIX, but MFC is a bit slow without any net connections (the class
hierarchy and additional overhead that it adds tend to slow it down).

If you're thinking of Java, I can't really help there. Word around the
net is that SWING (the new Java GUI toolkit) is a bit of a resource hog
(memory, threads, etc.) and that Tk is a better way to go. There's also
Jacl, which is Tcl/Tk written in Java.

Check out some of the "success stories" on our website (can someone post
other sites too...):

http://www.scriptics.com

-- Scott Redman
-- Scriptics Corp.


Russ Paielli wrote:
>
> I am absolutely convinced that Tcl/Tk is the greatest thing since sliced
> bread for many applications. However, I am just a bit confused about its
> practical limitations. For what type of graphical applications is it
> better to give up on Tcl and use Java or C/C++/Motif?
>
> For example, here at NASA Ames we do lots of work on decision support
> tools for air traffic controllers. These tools involve full-screen map
> displays showing the positions of the aircraft in a region, with several
> windows that can be brought up to set configuration parameters, detect
> and resolve potential conflicts, and perform many other functions.
> These run on a network of Sun Workstations and are typically programmed
> in C with Motif.
>
> Some of this software will eventually be redesigned and rewritten in
> object-oriented C++. Will I make a fool of myself if I propose that the
> graphical part of it (or at least some of the graphical part of it) be
> written in Tcl?
>

Paul E. Lehmann

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
One of the questions I would ask is "Who is going to maintain the code?"
I work for the National Weather Service and The "Modernization" of the
Weather Service has resulted in the deployment of The Advanced Weather
Information Processing System being installed at all the National Weather
Service Offices and River Forecasts Centers in the entire United States.
Tcl/Tk is used in abundance in AWIPS GUIs. As a systems test coordinator, I
expect that there are some major problems with the GUIs in AWIPS. This does
not mean that Tcl/Tk is to blame but it does point out the problems involved
in who writes the code, who maintains the code and the lack of "Official or
contract" software support. It is my feeling the the National Weather
Service simply does not have the resources or staff to follow news groups to
learn of the latest patches and correct problems pointed out by the user
community. This may not be your situation. I think it best to evaluate the
full ramifications before deciding on which software to use. I think Tcl/Tk
is pretty neat stuff but I do not like the idea of the National Weather
Service using peoples lives as test grounds for software they can not
adequately support.


Russ Paielli <rpai...@mail.arc.nasa.gov> wrote in message
news:3713D945...@mail.arc.nasa.gov...

Cameron Laird

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
In article <DYRQ2.9$q42....@news.abs.net>,

Paul E. Lehmann <pleh...@fred.net> wrote:
>One of the questions I would ask is "Who is going to maintain the code?"
>I work for the National Weather Service and The "Modernization" of the
>Weather Service has resulted in the deployment of The Advanced Weather
>Information Processing System being installed at all the National Weather
>Service Offices and River Forecasts Centers in the entire United States.
>Tcl/Tk is used in abundance in AWIPS GUIs. As a systems test coordinator, I
>expect that there are some major problems with the GUIs in AWIPS. This does
>not mean that Tcl/Tk is to blame but it does point out the problems involved
>in who writes the code, who maintains the code and the lack of "Official or
>contract" software support. It is my feeling the the National Weather
>Service simply does not have the resources or staff to follow news groups to
>learn of the latest patches and correct problems pointed out by the user
>community. This may not be your situation. I think it best to evaluate the
>full ramifications before deciding on which software to use. I think Tcl/Tk
>is pretty neat stuff but I do not like the idea of the National Weather
>Service using peoples lives as test grounds for software they can not
>adequately support.
.
.
.
I deeply respect your awareness of the frailties of
such "neat stuff" as Tcl/Tk. Is there a model for
software that deserves confidence? Would you recom-
mend the NWS contract with a provider to monitor the
state of the Tcl/Tk source base and assume responsi-
bility for patches and updates?

Cameron Laird

unread,
Apr 13, 1999, 3:00:00 AM4/13/99
to
In article <3713E000...@scriptics.com>,
Scott Redman <red...@scriptics.com> wrote:
.
.
.

>above. If you're targeting NT and UNIX, then definitely. If you're daring
>and want to try MFC, MainWin (from MainSoft, www.mainsoft.com) can provide
>it on UNIX, but MFC is a bit slow without any net connections (the class
>hierarchy and additional overhead that it adds tend to slow it down).
.
.
.
I don't understand the "net connections" part--are you saying
that in a remote graphical service situation, MFC's network
overhead is higher than that of Tk or other toolkits, for
comparable tasks? I agree ... Was your claim elliptic for
"MFC is a bit slow unless your network connection is a high-
bandwidth one"?

mo

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Russ Paielli wrote:

You should not need to "give up" on any of these tools. You just need
to choose the tool that is best for each job you want to get done.
Tcl links easily to C or C++ code and you can use Tcl Blend to
call Java methods directly from Tcl code or implement commands in
Java code.

> I am absolutely convinced that Tcl/Tk is the greatest thing since sliced
> bread for many applications. However, I am just a bit confused about its
> practical limitations. For what type of graphical applications is it
> better to give up on Tcl and use Java or C/C++/Motif?

In this case, you would NOT want to use the Tk canvas for the
"full screen map" part because the canvas does not scale but
you could use it to prototype a widget that you would later implement
in C. You would want to use Tk for the "configuration stuff" as it
provides lots of handy widgets like buttons, scrollbars, and so on.

> For example, here at NASA Ames we do lots of work on decision support
> tools for air traffic controllers. These tools involve full-screen map
> displays showing the positions of the aircraft in a region, with several
> windows that can be brought up to set configuration parameters, detect
> and resolve potential conflicts, and perform many other functions.
> These run on a network of Sun Workstations and are typically programmed
> in C with Motif.

Remember the 90-10 rule. You will only need to write 10% of your code
in C or C++ for speed reasons, the rest can be written in Tcl. Remember
that you will spend a lot less time if you prototype your application
in Tcl/Tk and then move parts of it to lower level code if you need to.

As for your original question, the only "practical limitation" I know
of is the fact that Tcl does not support OO like features without
extensions (please do not flame me, I am talking about OO classes and
instance data members not the OO like tk widgets). Everyone and there
mom has written one but there is still no "standard" way to OO in Tcl.

later
Mo DeJong
dejong at cs.umn.edu

Chang LI

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Russ Paielli wrote:
>
> I am absolutely convinced that Tcl/Tk is the greatest thing since sliced
> bread for many applications. However, I am just a bit confused about its
> practical limitations. For what type of graphical applications is it
> better to give up on Tcl and use Java or C/C++/Motif?
>

Tcl/Tk + C/C++ is enough for graphical applications.
No Java, it is poor on performance;
No Motif, it is slow and complicated.
The foundation of Tk is sound.

> For example, here at NASA Ames we do lots of work on decision support
> tools for air traffic controllers. These tools involve full-screen map
> displays showing the positions of the aircraft in a region, with several
> windows that can be brought up to set configuration parameters, detect
> and resolve potential conflicts, and perform many other functions.
> These run on a network of Sun Workstations and are typically programmed
> in C with Motif.
>

What you can do is write your own widgets for Tk.



> Some of this software will eventually be redesigned and rewritten in
> object-oriented C++. Will I make a fool of myself if I propose that the
> graphical part of it (or at least some of the graphical part of it) be
> written in Tcl?
>

GUI with Tk, others with C/C++.
I guess you have seen some ugly GUI program with Tk.
The problem was not the Tk itself. The problem was that author did not
use the Tk rightly.

--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
--------------------------------------------------------------

Chang LI

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Scott Redman wrote:
>
> I'd probably use Tk for the GUI for a C or C++ application for the reasons
> above. If you're targeting NT and UNIX, then definitely. If you're daring
> and want to try MFC, MainWin (from MainSoft, www.mainsoft.com) can provide
> it on UNIX, but MFC is a bit slow without any net connections (the class
> hierarchy and additional overhead that it adds tend to slow it down).
>

I have to say that the Tk implementation on NT or Windows are poor
performance.
The reason is the poor X Window Emulation Library that someone has
posted.
At present Tk can not compete MFC on speed and look and feel on Windows.
But I think Tk's foundation is sound and can be improved. And Tk
provided
a much simpler solution for GUI design.

I guess you said that MFC was poor on Unix.

Daniel

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

> For example, here at NASA Ames we do lots of work on decision support
> tools for air traffic controllers. These tools involve full-screen map
> displays showing the positions of the aircraft in a region, with several
> windows that can be brought up to set configuration parameters, detect
> and resolve potential conflicts, and perform many other functions.
> These run on a network of Sun Workstations and are typically programmed
> in C with Motif.

At one of the Scriptics Tcl/Tk classes I met one guy from he Air Force who
was working in a project for displaying radars and missile sites over a high
definition map, and then click on the radars in real time to see some
parameters. Tcl/Tk with custom extensions seemed the perfect solution for him
Your problem and the solution sound simialr: use k for the graphics part and
C for the part that has to be fast or that is already written and you can
just wrap it up

Greetings

Daniel

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Chang LI

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Paul E. Lehmann wrote:
>
> One of the questions I would ask is "Who is going to maintain the code?"
> I work for the National Weather Service and The "Modernization" of the
> Weather Service has resulted in the deployment of The Advanced Weather
> Information Processing System being installed at all the National Weather
> Service Offices and River Forecasts Centers in the entire United States.
> Tcl/Tk is used in abundance in AWIPS GUIs. As a systems test coordinator, I
> expect that there are some major problems with the GUIs in AWIPS. This does
> not mean that Tcl/Tk is to blame but it does point out the problems involved
> in who writes the code, who maintains the code and the lack of "Official or
> contract" software support. It is my feeling the the National Weather
> Service simply does not have the resources or staff to follow news groups to
> learn of the latest patches and correct problems pointed out by the user
> community. This may not be your situation. I think it best to evaluate the
> full ramifications before deciding on which software to use. I think Tcl/Tk
> is pretty neat stuff but I do not like the idea of the National Weather
> Service using peoples lives as test grounds for software they can not
> adequately support.
>

Do you means the Tcl/Tk's service is poor?
It is an open source software. If a company sold you the solution it
will
provide the support for the software. Tcl/Tk 8.0.x is a mature product.
I do no think there are big problems for the GUI design.

Could you please post the list of the major problems you may expect?



> Russ Paielli <rpai...@mail.arc.nasa.gov> wrote in message
> news:3713D945...@mail.arc.nasa.gov...
> >

--

Volker Hetzer

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Russ Paielli wrote:
>
> I am absolutely convinced that Tcl/Tk is the greatest thing since sliced
> bread for many applications. However, I am just a bit confused about its
> practical limitations. For what type of graphical applications is it
> better to give up on Tcl and use Java or C/C++/Motif?
I see no need to give up on Tcl, but youmight wish to add a widget or two.
Tk is designed to be extensible that way.

> For example, here at NASA Ames we do lots of work on decision support
> tools for air traffic controllers. These tools involve full-screen map
> displays showing the positions of the aircraft in a region, with several
> windows that can be brought up to set configuration parameters, detect
> and resolve potential conflicts, and perform many other functions.

If I had to make a decision I'd do all the gui in tk, except the map stuff.
For that I would create a map widget with lots of high-level widget
commands like slide/change_map or add/move/remove_car or whatever you like.
For this you can then use motif, naked X or whatever you need.
Is it possible to integrate qt-widgets into tk?


> Some of this software will eventually be redesigned and rewritten in
> object-oriented C++. Will I make a fool of myself if I propose that the
> graphical part of it (or at least some of the graphical part of it) be
> written in Tcl?

You will not. All the dialogs, menus, lists, texts and so on can be done
nicely in tk without too much performance penalty. However, you will save
implementation time and get (usually) better maintainability and extensibility.
I'd suggest a mixture of Tcl/Tk and packages written in C/C++ wherever
the profiler says your code is too slow.

Greetings!
Volker

Volker Hetzer

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Cameron Laird wrote:

> The biggest liability of Tk in this general domain
> is simply that it doesn't have a well-established
> widget set beyond the core.

There is BWidget. Found it invaluable.

Volker

Donal K. Fellows

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
In article <DYRQ2.9$q42....@news.abs.net>,

Paul E. Lehmann <pleh...@fred.net> wrote:
> One of the questions I would ask is "Who is going to maintain the
> code?" I work for the National Weather Service and The
> "Modernization" of the Weather Service has resulted in the
> deployment of The Advanced Weather Information Processing System
> being installed at all the National Weather Service Offices and
> River Forecasts Centers in the entire United States. Tcl/Tk is used
> in abundance in AWIPS GUIs. As a systems test coordinator, I expect
> that there are some major problems with the GUIs in AWIPS. This
> does not mean that Tcl/Tk is to blame but it does point out the
> problems involved in who writes the code, who maintains the code and
> the lack of "Official or contract" software support. It is my
> feeling the the National Weather Service simply does not have the
> resources or staff to follow news groups to learn of the latest
> patches and correct problems pointed out by the user community.
> This may not be your situation. I think it best to evaluate the
> full ramifications before deciding on which software to use. I
> think Tcl/Tk is pretty neat stuff but I do not like the idea of the
> National Weather Service using peoples lives as test grounds for
> software they can not adequately support.

You buy support separately. IIRC there are companies listed in the
FAQ that sell full-scale support. It *will* cost though - support
always costs, no matter who does it or what is being supported.

I would also point out that not all full commercial packages are as
well supported as they ought to be (and as you might naďvely expect.)
OSS merely means that there is a Free and Open Market in support; your
choice of software is not bound by the level/cost of support offered
by the "manufacturer".

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Donal K. Fellows

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
In article <37144967...@sni.de>,
Volker Hetzer <hetze...@sni.de> wrote:
> You will not [make a fool of yourself]. All the dialogs, menus,

> lists, texts and so on can be done nicely in tk without too much
> performance penalty. However, you will save implementation time and
> get (usually) better maintainability and extensibility. I'd suggest
> a mixture of Tcl/Tk and packages written in C/C++ wherever the
> profiler says your code is too slow.

Most GUI code tends not to be performance critical (users truly can't
see the difference between 1ms and 6ms to pop up a menu) and the rest
can almost always be done with the aid of specialised widgets or
[canvas] items. And the [text] widget is great for those situations
where you want a little bit of formatted hypertext; without Tk you'd
normally just leave those bits alone as plain text since the amount of
effort to do something better would be prohibitive.

In short, Tk would be very nice even if it didn't have the [canvas]
and [text] widgets and it wasn't extensible, but seeing as all those
extra capabilities *are* there and you can add to them with your own,
Tk is utterly brilliant. And well-engineered too!

Cameron Laird

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
In article <371449FE...@sni.de>,

You're quite right. BWidget deserves a lot of attention. And
I'm satisfied now that its license is practical.

Bob Techentin

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Cameron Laird wrote:
>
[snip]

>
> You're quite right. BWidget deserves a lot of attention. And
> I'm satisfied now that its license is practical.
> --

Is this a change? I was just having a discussion yesterday
about GPL vs LGPL and the BWidget toolkit. I was under the
impression that it *was* GPL, but checking the Unifix website
FAQ (http://www.unifix-online.com/BWidget) it os *now* LGPL.

If this is a change, then it is good news to me.

--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Bob Techentin

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Volker Hetzer wrote:
> I'd suggest a mixture of Tcl/Tk and packages written in C/C++ wherever
> the profiler says your code is too slow.
>

Is there a profiler? For Tcl 8.x?

I spent a little time looking through the FAQ part 4 and found 'tprof'
which works with Tcl 7.6 on HP/Linux/Irix. 'Tycho' claimed to have a
profiler in the FAQ entry, but I haven't found it.

The FAQ part 5 lists 'Profile Tcl Code' as a redefinition of 'proc'
which is available from the author, and something called 'Profiler'
which sounds more capable, but works only with Tcl 7.6.

I also noticed that Scriptics' roadmap included a profiler.

What are people using to profile Tcl code? Is there a tool or package
that works well with Tcl 8.0 and/or 8.1? Tcl-only would be nice, but I
could live with some compiled code if I had to.

Thanks,
Bob

Carsten Zerbst

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Bob Techentin wrote:
>
> Volker Hetzer wrote:
> > I'd suggest a mixture of Tcl/Tk and packages written in C/C++ wherever
> > the profiler says your code is too slow.
> >
>
> Is there a profiler? For Tcl 8.x?
>


Try sage, the profiler made by John Stump,

url is
http://www.geocities.com/SiliconValley/Ridge/2549/sage/index.html

Bye, Carsten

Bob Techentin

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

Thank you! I saw sage too, but the link in the FAQ part 4 is broken. I
thought it had been lost to the ages.

Christopher Nelson

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Bob Techentin wrote:
>
> Volker Hetzer wrote:
> > I'd suggest a mixture of Tcl/Tk and packages written in C/C++ wherever
> > the profiler says your code is too slow.
> >
>
> Is there a profiler? For Tcl 8.x?

TclX has a profiler that works quite well. I've written some off-line analysis
tools for the data dump (which can be quite large).

Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!

Christopher Hylands

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Bob Techentin <techenti...@mayo.edu> writes:

> I spent a little time looking through the FAQ part 4 and found 'tprof'
> which works with Tcl 7.6 on HP/Linux/Irix. 'Tycho' claimed to have a
> profiler in the FAQ entry, but I haven't found it.

Tycho 0.2 used the TclX Profiler with Tcl7.6 and had a start at a gui for it.
We pulled the profiler out because our gui was not working quite
right, so Tycho0.2.1 and Tycho0.3alpha do not include it.

If the profile command had been available in the core in Tcl8, we probably
would have polished the GUI and kept it. However, shipping just the TclX
profile command as a standalone extension was too much effort.

There is some documentation at
ftp://ptolemy.eecs.berkeley.edu/pub/tycho/tycho0.2/tycho0.2/doc/coding/performance.html

-Christopher
--
Christopher Hylands, Ptolemy Project Manager University of California
c...@eecs.berkeley.edu US Mail: 558 Cory Hall #1770
ph: (510)643-9841 fax:(510)642-2739 Berkeley, CA 94720-1770
home: (510)526-4010 (if busy -4068) (Office: 493 Cory)

lvi...@cas.org

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

According to Russ Paielli <rpai...@mail.arc.nasa.gov>:
:For example, here at NASA Ames we do lots of work on decision support

:tools for air traffic controllers. These tools involve full-screen map

Check out some of the success stories that Scriptics, the Consortium,
etc. have on their sites. Things like the US television network NBC
using Tcl/Tk for real time control of tv feeds, or CPU's use of Tcl/tk
for real time control of oil riggings. Or De Clarke's data mining of
data from satellite telemetry - and so on. I thought I recalled someone
in the air traffic field doing a paper at one of the conferences. However,
I am unable to locate that info at this time.

I know that at one point in the past someone used itcl to write an
air traffic controller simulator... The old reference is still in
<URL: http://www.purl.org/NET/Tcl-FAQ/part4.html> though I've not
checked recently to see if the URL to it is still fresh.


If I do an altavista search on +NASA +tcl +tk I see more than 1500 hits.
Of those, several of the initial ones I checked happened to be NASA staff
writing interfaces of various types. So you may not be the first person
in your area to use Tcl <grin>.
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

lvi...@cas.org

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

According to Paul E. Lehmann <pleh...@fred.net>:
:One of the questions I would ask is "Who is going to maintain the code?"

:not mean that Tcl/Tk is to blame but it does point out the problems involved


:in who writes the code, who maintains the code and the lack of "Official or
:contract" software support. It is my feeling the the National Weather

I don't understand the 'lack of "Official or contract" software support'
comment. There are a number of companies who officially support Tcl - including
Scriptics itself. Why would you not just contract with one of these companies?

:community. This may not be your situation. I think it best to evaluate the


:full ramifications before deciding on which software to use. I think Tcl/Tk

That is true. For instance, I have used a number of so called 'vendor supported
products'. None of them provided me 10% of the support I find on comp.lang.tcl.

lvi...@cas.org

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

According to mo <n...@spam.com>:
:instance data members not the OO like tk widgets). Everyone and there

:mom has written one but there is still no "standard" way to OO in Tcl.

though to be fair, there is no 'standard way' to do graphics in C++, right?
There are many extensions, none of which are 'standard' in any sense of the
word. There's Java - but then its implementation isn't 'standard' - ie
Microsoft's virtual machine works somewhat differently than Sun's, and
the people I deal with who have attempted to write commercial Java products
tell me of the pain of getting one Java app to run identically in Windows,
the various Unix platforms, and MacOS ...

lvi...@cas.org

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

According to Bob Techentin <techenti...@mayo.edu>:

:Carsten Zerbst wrote:
:>
:> Bob Techentin wrote:
:> Try sage, the profiler made by John Stump,

:>
:> url is
:> http://www.geocities.com/SiliconValley/Ridge/2549/sage/index.html
:>
:> Bye, Carsten
:
:Thank you! I saw sage too, but the link in the FAQ part 4 is broken. I
:thought it had been lost to the ages.


Be sure to email FAQ maintainers when you find broken links - and even
more certain to email them when you find the new homes - so they can update
their FAQs.

Scott Redman

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
I would have to agree with you in that Tk is slower than it could be.
MFC has problems in speed on Windows due to C++-related issues in the
class library (if you do anything that Microsoft doesn't give you
out-of-the-box, it's slower than it should be).

Tk vs. MFC on Windows isn't really what I was comparing. I was
comparing different solutions for Unix. Sorry for the confusion.

-- Scott

Chang LI wrote:
>
> Scott Redman wrote:
> >
> > I'd probably use Tk for the GUI for a C or C++ application for the reasons
> > above. If you're targeting NT and UNIX, then definitely. If you're daring
> > and want to try MFC, MainWin (from MainSoft, www.mainsoft.com) can provide
> > it on UNIX, but MFC is a bit slow without any net connections (the class
> > hierarchy and additional overhead that it adds tend to slow it down).
> >
>
> I have to say that the Tk implementation on NT or Windows are poor
> performance.
> The reason is the poor X Window Emulation Library that someone has
> posted.
> At present Tk can not compete MFC on speed and look and feel on Windows.
> But I think Tk's foundation is sound and can be improved. And Tk
> provided
> a much simpler solution for GUI design.
>
> I guess you said that MFC was poor on Unix.
>

lvi...@cas.org

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to

According to Bob Techentin <techenti...@mayo.edu>:
:Cameron Laird wrote:
:> You're quite right. BWidget deserves a lot of attention. And
:If this is a change, then it is good news to me.


To tie this diverging of the thread to a very old one, here is a case
of a nice looking widget set, but which comes without man pages.

Now, why do I want man pages? Because I have a mix of people writing Tcl.
Some of these people are willing/able to dig into code, or go exploring thru
the 100 gigabytes of disk on our intranet to find web pages or text files
documenting widgets, while others are not willing or able to do so.

Certainly I could (and in fact have) copy files into various directories.
But the bottom line is that the more inconvenient it is to find programming
information about a widget set, the less likely someone is going to use it.

I am not saying that man pages are the only format acceptable. What I am
saying is that having man pages available on Unix (WinHelp on Windows/Mac
whatever files on MacOS/etc.) is going to make it more likely that others
will use an extension AND more likely that someone will read the docs before
emailing the author, etc.

Jim McCusker

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
lvi...@cas.org wrote:
>
> According to Bob Techentin <techenti...@mayo.edu>:
> :Cameron Laird wrote:
> :> You're quite right. BWidget deserves a lot of attention. And
> :If this is a change, then it is good news to me.
>
> To tie this diverging of the thread to a very old one, here is a case
> of a nice looking widget set, but which comes without man pages.

They dont have man pages per se, but they do have html documentation on
their web site. This is easily downloaded locally, and my be more useful
than plain text man pages (hyperlinks and such)

Jim
--
Jim McCusker | Class of '99, BA Computer Science & Cognitive Science
jc0...@uhura.cc.rochester.edu | http://cif.rochester.edu/~fprefect
~Those who do not understand Unix are condemned to reinvent it,
poorly.~
~~Henry
Spencer

Cameron Laird

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
In article <7f4o0t$mcs$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
>
>According to Bob Techentin <techenti...@mayo.edu>:
>:Cameron Laird wrote:
>:> You're quite right. BWidget deserves a lot of attention. And
>:If this is a change, then it is good news to me.
>
>
>To tie this diverging of the thread to a very old one, here is a case
>of a nice looking widget set, but which comes without man pages.
>
>Now, why do I want man pages? Because I have a mix of people writing Tcl.
>Some of these people are willing/able to dig into code, or go exploring thru
>the 100 gigabytes of disk on our intranet to find web pages or text files
>documenting widgets, while others are not willing or able to do so.
>
>Certainly I could (and in fact have) copy files into various directories.
>But the bottom line is that the more inconvenient it is to find programming
>information about a widget set, the less likely someone is going to use it.
>
>I am not saying that man pages are the only format acceptable. What I am
>saying is that having man pages available on Unix (WinHelp on Windows/Mac
>whatever files on MacOS/etc.) is going to make it more likely that others
>will use an extension AND more likely that someone will read the docs before
>emailing the author, etc.
.
.
.
Now I don't understand. Are we talking about BWidget? Do we all agree
that <URL:http://www.unifix-online.com/BWidget/BWman/contents.html> has
the kind of information that developers need? Are you saying that you
want this content translated into nroff source, or you want it to be
part of the distribution's install, or ...?

lvi...@cas.org

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to

According to Jim McCusker <mccu...@iname.com>:

:lvi...@cas.org wrote:
:>
:> According to Bob Techentin <techenti...@mayo.edu>:
:> :Cameron Laird wrote:
:> :> You're quite right. BWidget deserves a lot of attention. And
:> :If this is a change, then it is good news to me.
:>
:> To tie this diverging of the thread to a very old one, here is a case
:> of a nice looking widget set, but which comes without man pages.
:
:They dont have man pages per se, but they do have html documentation on

:their web site. This is easily downloaded locally, and my be more useful
:than plain text man pages (hyperlinks and such)


To _some_ people it is more useful. To other people it becomes less
useful. Say you are looking at a piece of code that is written in Tk
and uses several packages. Now, you have a bug that you need to fix.
You do a man page for Tk, BLT, Tix, and a number of other packages, you
use an HTML browser to look at BWidget doc, and if the author only
supplies the text of the source library then you go looking for it
hopefully in some accessible location on a machine to which you have
login or NFS , etc. access.


That kind of 'searching for the answer' strategy is fine for some
programmers. Others have less patience. And people who are _using_
Tk and not doing a lot of programming, but need to tweak programs written
by others tend to have no patience. They typically want _one_ command
to look at program doc ... 'like Perl' or 'like Java', etc...

Volker Hetzer

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Cameron Laird wrote:
>
> In article <7f4o0t$mcs$1...@srv38s4u.cas.org>, <lvi...@cas.org> wrote:
[...]

> >I am not saying that man pages are the only format acceptable. What I am
> >saying is that having man pages available on Unix (WinHelp on Windows/Mac
> >whatever files on MacOS/etc.) is going to make it more likely that others
> >will use an extension AND more likely that someone will read the docs before
> >emailing the author, etc.
> .
> .
> .
> Now I don't understand. Are we talking about BWidget? Do we all agree
> that <URL:http://www.unifix-online.com/BWidget/BWman/contents.html> has
> the kind of information that developers need? Are you saying that you
> want this content translated into nroff source, or you want it to be
> part of the distribution's install, or ...?
I'd like to have it translated into nroff and part of the distributions install,
just like the tcl/tk base installation.
But, since I don't pay anything for it, I can only suggest, not request it.

Greetings!
Volker

Volker Hetzer

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Bob Techentin wrote:
>
> Volker Hetzer wrote:
> > I'd suggest a mixture of Tcl/Tk and packages written in C/C++ wherever
> > the profiler says your code is too slow.
> >
>
> Is there a profiler? For Tcl 8.x?
I was under the impression that TclPro contained one. Sorry.
What we do here is a simple profiling using the clock clicks command.

See you!
Volker

Reply all
Reply to author
Forward
0 new messages