From octave-graphics-request at bevo dot che dot wisc dot edu  Mon Oct 28 15:39:35 1996
Subject: Re: GUI interface for Octave
From: Carl Leitner <bigcarl at email dot unc dot edu>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
cc: octave-graphics at bevo dot che dot wisc dot edu
Date: 	Mon, 28 Oct 1996 16:39:26 -0500 (EST)

On Mon, 28 Oct 1996, John W. Eaton wrote:

> To further start things off, I will comment on something that Carl
> Leitner sent to me:
> 
> : This is primarily the reason I asked.  I would be interested in working on
> : this.  I have some background with expect/tcl-tk, as well as the
> : X-interface w/ Matlab.  But before I begin doing so, I would like to
> : bounce some ideas around.  Here is what I am looking at:
> : 	1) Trying to make it as close to Matlab's interface as possible
> : 	2) Either: 
> : 		Creating a new loading function to filter the X
> : 		commands to expectk and the non-x to octave.
> : 		(This could prevent people from typing in X
> : 		commands or create incompatibilities w/ other
> : 		versions of an  X-interface)
> : 	   Or:
> : 		Running any x-capable *.a files under expectk
> : 		and piping the appropriate stuff to octave
> : 		(This would require two binaries
> : 			octave
> : 		 and 	octave_tcl)
> : 
> : What do you see as advantages/disadvantages to any of these aproaches.  
> : Are there are aproaches that might be equally fit, or better?
> 
> I don't think we need to define new syntax, or modify the parser to
> pass commands to some other program.  In fact, for graphics, one of
> the problems is that I tried to allow gnuplot commands to work
> directly rather than just specifying a function call interface.  Now
> gnuplot and Octave's command lines tend to be slightly incompatible as
> features are added.  I would prefer to avoid problems like this in the
> future by using a function call interface and not defining new syntax
> unless it is absolutely necessary.


Elron and I have been discussing methods of implementation, and I have one
method, that I think will be reasonable, and is much different than the
ones above.  A lot of this is based on what I beleive is happening w/ the
octave code/parser (but this may very well be flawed).  Elron's idea was
to create an interpreter for tcl/tk in Octave, and define a function, tcl,
w/in the octave parser that will call tcl/tk commands.  The method of
calling (which I will explain in just a sec), I beleive will allow pretty
much full access to the tcl/tk language from w/in Octave.   Here is what I
am looking at write now, but I am open to any suggestions, criticism...

1) The idea is to make the tcl a text function, and when it is called the
first time, it will initialize the tcl/tk interpreter.  In order to allow,
as full as possible access to tcl/tk, which would mean language conflicts
btwn octave and tcl/tk, I think it would be a good idea to indicate
commands that are to be evaluated in octave w/:
	!![ xxx xxx xx ... ]!!
where xxx ... is the command.  We could use eval, but this would make it
more difficult to read, and would provide a conflict w/ tcl/tk's version
of eval.  Therefore, in octave you could do something like:
	tcl label .button.amount -tesxt !![ num2str(num_users ]!!
where num2str(num_users) is an octave command.  
Elron suggested using something like:
	tcl (['label .button.amount -text ' num2str(num_users)])
but it seems that, although fine for this example, lots of ambiguties
could arise as to what is intended for tcl/tk and octave.  The reason I
think we should define the tcl as a text function is to avoid the
pareser from evaluating/escaping anything that we don't want.  I chose the
!![  ]!! combination to be something that I don't think would occur in
octave, so it would be safe to use.  I could also set this up as a
default, and let the user define it in the rc file.  I should also note
here that I have a limited experience bison and flex :-)

2) Now that we have a basic interface to the tcl/tk interpreter, we want
tcl to access octave data fairly directly.  This can be done realtively
easily w/ the way the tcl/tk interpreter is set up.  We can therefore make
a tcl/tk command something like:
	set a [matrixe (Matrix_name row col)] 
or:
	set row [matrixr (Matrix_name row)]
or:
	set row [matrixc (Matrix_name col)]
This would be done in C, along w/ some very basic access/setting routines.
We can set the interpreter to load a tcl/tk library file to expand these
basic things to more complicated/robust calls.  This would allow
relatively quick access to data and would avoid recompilation to make
changes, additions to the code.  We could also allow the user the specify
an alternative tcl/tk library file.


3)  The last part of this process would be to simulate, as close as
possible, the GUI interface of Matlab.  Elron suggested that once we have
in tcl interpreter in place, we could create a series of m-files that
would simulate the GUI interface.  This is what he wrote.

> Once you have a tcl and tk interpreter in Octave, you can define
> m-files for each of the Matlab HandleGraphic functions.  For instance,
>
> function handle = uicontrol(...) 
>
> % use octave and/or tcl expressions to parse the input args
> % and build a string matrix that contains a tk expression
> % to make the control...
>
  handle = tcl command_string

Then, the only difference btwn the octave GUI interface and Matlab's would
be the addition of !![   ]!!  where apropriate, and something along these
lines would be neccessary anyways.




I think this pretty much sums up where I am at this point.


						Carl