
BUG LIST:

palette.tcl and dialog.tcl need to be ported to Python code.

Pinnable windows do not pin.

"menu -postCommand" does not return value to caller.

"send" is not implemented.

The rivet.selection.handle() and rivet.selection.own() methods exist but
are not completely implemented, Python callbacks are not hooked up.
The "get" and "set" methods work, however.

Do something with WITH_READLINE and rivet.mainloop so that you get a wish-like
environment.

Control-C should interrupt and stop rivet.mainloop.  It does nothing now.

Check to make sure that names of widgets get removed from tk's id table
when rivet object is destroyed, to avoid leaking memory.

Using keyword arguments causes memory leaks.  Appearently, Python does
not decref the dictionary that contains the keyword arguments that are
passed to C functions.  I regard this as a Python 1.3 bug.

The standard option "takefocus" cannot be set to a script, for now it
can only have the values 0 or 1.  

These utility functions are not yet available in the Python rivetmodule:
	tk_focusNext, tk_focusPrev, tk_focusContinue,
	tk_focusFollowsMouse, and tk_popup 

Delayed creation of windows inside text windows with:
	textwindow.window_create(index, 'create', python_callable)
does not work.  The workaround is to use the simpler form of window create:
	textwindow.window_create(index, 'window', rivetobj)

The reporting of errors in callbacks is sufficient, it prints the call stack
to stdout, but it probably could use some more work.  It should be possible
to write a function to handle errors in callbacks, and even support the
same kind of prompting system that tk uses.

Use configure for building the makefiles.

Doc note: prolog.ps is located in the same places as tcl/tk.  Maybe it
should be copied into the rivet source directories.

The tkStrictMotif variable is set to FALSE and changes to it are ignored.

The variable classes in rivetutil have one hole where the lower level
variable name shows through: cget and configure will return the string
name for the variable, not the variable class instance that was previously
assigned to it.

There is some global data that prevents more than one rivet application
within a single address space (only one rivet_main_window, for
example).  I believe Tk itself has some similar assumptions.  This is
probably only a concern if porting to other runtimes, such as secure
applets ala java.


