From octave-graphics-request at bevo dot che dot wisc dot edu Wed Nov 13 00:39:54 1996 Subject: Re: GUI interface for Octave From: "John W. Eaton" To: Carl Leitner Cc: "John W. Eaton" , octave-graphics@bevo.che.wisc.edu Date: Wed, 13 Nov 1996 00:39:41 -0600 On 12-Nov-1996, Carl Leitner wrote: : Okay this seems reasonable, but one question: There are more functions, : and certainly more control, availible to the user under tk. These : may or may not be available in other packages. Should we only establish a : minimum number of GUI tools (such as the ones available in MATLAB) -- : which severly limit the user's control? I don't think we have to go with a least-common-denominator approach. It is ok if Octave supports some things with Tk that can't be done (easily or even at all) in other toolkits. That situation is not necesarily great, but it is acceptable. The thing that is not acceptable to me is to design the interface to the GUI toolkit so that it makes it very difficult to switch to something different in the future. : Maybe a reasonable solution is to figure out a reasonably large base : requirement of the toolkit, which are very cleary established. Implement : these in C++ classes. Yes, this is what I would like to do, but I don't think I really have enough experience working with different toolkits to actually do it well. Another problem that remains to be solved is how to actually pass values to and from the toolkit. I assume this should not be too much of a problem with Tk, but I am no expert. : Then, also add direct access to tk functions. This is probably ok as long as other more portable mechanisms are available. : > Do you have any experience working with the event mechanism of Tcl/Tk? : : Nope. I found that readline already has a hook available for calling event handlers, so it should be easy to use that to arrange to call (for example) Tcl_DoOneEvent() from inside readline. That way, while readline is waiting for additional input, it will also be checking for Tcl/Tk (or other toolkit) events. jwe