Re: GUI work (was: Graphical help browser)

[Ryan Rusaw]

On Fri, Jan 23, 2009 at 2:09 PM, John Swensen <address@hidden> wrote:
>
> 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
>

John,

As part of my work on octave/eclipse integration, I implemented an
Octave interface for DBGP, http://www.xdebug.org/docs-dbgp.php, which
meets most of the requirements you specify here. DBGP has an advantage
that several editors already have support for the protocol available.

Emacs: http://code.google.com/p/geben-on-emacs/
Vi: http://www.vim.org/scripts/script.php?script_id=1152

A snapshot of the source code is available at
http://octclipse.svn.sourceforge.net/viewvc/octclipse/trunk/octave_dbgp.tar.gz?view=tar

If there is interest, I could spend some time working on removing the
external threading and socket library dependencies, and get a patch
ready for inclusion directly into Octave.

Ryan