Victor Wagner vitus at
Tue Aug 31 20:36:22 CEST 1999

Phil Hunt <philh at> wrote:
: In article <7ps4ma$n06$1 at wagner.wagner.home>
:            vitus at "Victor Wagner" writes:

:> This is tcl/tk. Almost no difference.

: If that is what you think, you obviously have a different aesthetic
: sense than me.

Of course, I have. I think that application is intended to do the job
not to draw funny pictures on screen, unless it is screensaver.

: Don't forget that Parrot will be able to do more than what is in that
: simple example. For example:

:    sub.fcol=red

But in tcl you can do

option add mywindow*Button.Background red
and achiveve the same effect. Moreover, in Parrot it seems to be coded
into app, but with Tcl option command it can be overriden by user
Xdefaults file.

: would mean ``make all components inside the current component
: default to having an attribute ``fcol'' with thew value ``red'' 
: (i.e red foreground); these defaults can be overridden by the
: attributes in the actual components''

: Creating a default attribute for a component-type will also
: be possible, e.g:

:    all.label.font=Helvetica

It is also possible with option database. 

: Could it write C output that calls the GTK+ library, or C++/Qt,
: or other language/GUI-toolkit combinations?
In principle could. Just define set of procedures named button, label
and so on which generate C source and use them instead of Tk.

But I think that hard coding interface into C code is not a good
approach. You should divide functionality of your application into small
pieces which are provided as scripting language commands. Thus you
clearly separate functionality from interface and if then you decide to
make web-based interface or command-line only interface for batch jobs
which run nightly, it would be simple.

: Would anyone want to do this in Tcl as opposed to Python? (Not
: wishing to get into another language war :-)).

I'm saying for scripting languages as a concept. I just happen to like
Tcl more than Python or Perl or Scheme, but them all are providing
simular levels of abstraction.

:> And parrot files would become runnable. But pretty
:> useless, becouse I've not seen any way to attach functionality to these
:> windows.

: Use subclassing.
No, thanks. I've large experience of programming with toolkits where you
need to create a subclass for each of hundreds dialogs in your program.
I'm avoiding OOP since that as much as possible. Of course, there are
cases, where OOP is The Right Thing, but interface design is not one of
them. At least if you need to subclass for each bit of functinality.
Victor Wagner @ home       =         vitus at 
I don't answer questions by private E-Mail from this address.

More information about the Python-list mailing list