Re: GUI work (was: Graphical help browser)

[John Swensen]

On Jan 23, 2009, at 2:30 PM, Pedro L. Lucas wrote:

> Hi, I'm developer of QtOctave. I would rather a new API to connect
> Octave with IDEs. This API should open pipes from Octave to IDE and
> from IDE to Octave. You could send commands to Octave and read results
> from those pipes. This pipes should be different of stdin and stdout
> used by user. Then IDE could send, for example, commands to read some
> matrix or read help from some command.
>
> I have read code of Octave and I think it could be written easyly. It
> doesn't need any thread or fork, only pipes.
>
> Every-IDE should use this API. Then you could use Emacs, OctaveDE or
> whatever you want. This API would be "multi-platform", it can be used
> in Windows or UNIX.
>
> Kind regards.

Once again, I think we should define an interface and let the guts be  
implemented independently.  For IDEs like OctaveDE, where the IDE and  
Octave are in the same process, pipes or some other IPC is complete  
overkill.  Plus I would guess they are slower than the straightforward  
function calls used by OctaveDE.  I think that similar to the new  
graphics frontend/backend, there should be a predefined interface  
which lists the common use cases for IDE to Octave communications and  
then let people implement the backend required to talk to their IDE.

That being said, I think there is a case to be made for having a  
direct backend (e.g. function call access as in octave_server) and an  
IPC backend (e.g. as proposed by you for pipes or recently via DBus).

I recently made a list of the expected functionality of this interface
1) Set, clear, and list breakpoints (maybe extend to watchpoints when  
octave supports such a thing)
2) Get a command history list (possibly incremental as in  
octave_server?)
3) Get a list of variables in the current scope and the global scope
4) Get or set a variable's value

I don't see a real reason to have it return help text, as that is  
something that can be pre-processed and put in a help browser.   
Although maybe it would be nice for custom m-files.  Maybe it makes  
sense to return the current search path, so the help browser can look  
through user-added directories and generate HTML-ized help.

John Swensen