> Why bother? the Motif interface that comes wih Python 0.9.9 is
> much cleaner than tk will ever be!
It also bloats python from 1MB to 3MB on the Sun, making it
realistically unusable for quick small programs. What Tk has going for
it (with Tcl), is that it is quick and small -- it doesn't require the
Motif library to be linked in. I think, though, that we could come up
with something *much* better than Tk, with more functionality, of
equivalent size and speed. STDWIN is, in some ways, a good start. What
it could use (from my limited experience with it):
1) a nice Motif-appearance set of widgets, implemented in Python or C,
to go on top of it. (A C implementation would be analogous to Tk.)
2) better (faster) access to the text buffer maintained by the textedit
widget.
The style proposed by EZD would be a nice way to go, as well, and might
be easy to map on top of STDWIN (which would mean a 3 layer system:
STDWIN on the bottom, "pezd" on top of that, some widget collection on
top of that). In EZD, things are done in terms of "graphical objects"
(lines, arcs, polygons, text), which can be created and arranged without
regard to whether or not any windows actually exist. Groups of
graphical objects are called "drawings". Graphical objects can be bound
into drawings, and their position and stacking order controlled.
Drawings can also then be mapped into "windows". Multiple drawings can
be mapped into any window. A drawing may be mapped into more than one
window. Optional clipping rects may be defined for each binding of a
drawing to a window. Each window can define its own coordinate space.
Events like mouse clicks or keystrokes are mapped by EZD to the drawing
object on which the event occurred. Redraws are done via callbacks
bound to the drawing objects. Each drawing object uses a set of
graphical primitives similar to those used in STDWIN. I'd have to
re-read the technical report
(ftp://gatekeeper.dec.com/pub/DEC/ezd/techreport.psf.Z) to be more
accurate than that.
Bill