This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AI is a pushover & UI


>bboett@bboett.dyndns.org said:
>> tcl/tk is an incredible messy thing, and very soons becomes un
>> debuggable and unreadable,
>
>I mostly lurk here, but I can't let this pass.  Whatever reasons there are
>for switching to SDL, Tcl/Tk is not ipso facto messy.  I've worked on
>projects
>with hundreds of thousands of lines of Tcl/Tk and they were well structured,
>readable and debuggable.

Heh, I think we stepped into sensitive ground here :-). Anyway, since the
question originally was directed to me, here is what I think about tcltk,
for what it is worth:

First, I would tend to agree with the epithet "undebuggable" though not
necessarily "unreadable". When you have a bug in your tcl script, either of
two bad things typically happens:

You get the infamous error message "Error reading tcl" which doesn't tell
you anything. Some minimal debugging support in tcl would be very helpful.
Like telling you on *what line* the program failed to read tcl ...

The other thing that may happen is even worse: nothing. The interpreter
reads the buggy line, but silently fails to execute it since it makes no
sense. For example, an obscure typo in a pack instruction may cause nothing
at all to be packed, thus leaving you with an empty window. This error is
kind of obvious, but there are other more subtle errors that will go
unnoticed and therefore cause a lot of problems later on.

In contrast, a C compiler fails if you feed it a line that makes no sense.
So you know immediately that something is wrong.

Then there are the platform issues. No tcltk platform is the other alike.
Not only do widgets look different, but they behave differently as well. In
order to make xconq work the same way under Windows, MacOS and Unix, I had
to introduce globals like "listb" and "textb" that have different values on
different platforms. Take a look at lines 218-251 in tkconq.tcl to see what
I mean.

This problem is to some extent unavoidable, since tcltk uses whatever
widgets are available, but it is still remarkable how similar SDL is on all
platforms.

Speaking about platforms, the level of support for different features in
tcltk varies a lot between different platforms. In tcltk for MacOS,
important stuff like clipping masks was not implemented, so I had to write
the missing code myself. Take a look inside tkmac.c to see what I mean.

The tcl language is actually both simple and powerful. I kind of like it
after spending a lot of time with it, but I also understand why many people
hate it. In particular, the packing algorithms and how they affect what
happens on the screen is an extremely obtuse topic. If you have done some
tcl coding, you know that some things have to be packed before others, and
that some kinds of padding work as expected while others do not. But you
never really understand why.

Finally, there is the performance issue. If you have a brand new 2 GHz
machine, performance may not matter, but on my tired old Mac G3 the tcltk
interface is slow whether I'm running MacOS or Linux. In contrast, the SDL
interface is fast. In fact, when I run the SDL interface under two layers
of emulation (MacOS on top of Mac-on-Linux on top of Linux) it is still a
lot faster than the native tcltk interface for either MacOS or Linux.

Hans














Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]