More GUI talk...

[John W. Eaton]

On 30-Mar-2008, Søren Hauberg wrote:

| When the user enters a command into the GUI it is then evaluated with
| "eval_string".

The problem with this method is that it fails for partial statements.
You won't be able to write

  if (some_condition) RET
    do_something (); RET
  endif

in your GUI input box.

There is another way to build a GUI that allows the normal readline
interface for Octave to be fully functional.  I first outlined the
method here:

  http://www.nabble.com/GUI-thoughts-to3172755.html#a3172755

and you can search the maintainers mailing list for "vte" to see other
threads about this.  John Swensen has done some work on a GUI with
this design and his code is here:

  http://sourceforge.net/projects/octavede

However, since Octave is not thread safe, neither of these GUI designs
can really work well since the GUI will block while Octave is
working (or crash, if you compile it so that separate threads are
possible because eventually I expect you will hit some bit of code
that can't be executed in two threads at once).

So I think the first thing to start looking at if we really want a
fully functional integrated GUI is to make Octave thread safe.

I believe that John Swensen's code tries to avoid the threading issues
and still provide some level of responsiveness by having Octave update
some global state at various places in the read-eval-print loop.

This method might not work on Windows systems since Windows doesn't
have POSIX ptys.  I think Cygwin provides an approximate
implementation using pipes, and that might form the basis for a
solution, though it might also be necessary to force Octave into
interactive mode then.  Michael Goffioul posted something about this
topic here:

  
http://www.nabble.com/need-help-diagnosing-readline-issue-under-cygwin-rxvt-to15481956.html#a15542409

jwe