Re: GUI work (was: Graphical help browser)

[Pedro L. Lucas]

>
> 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 agree with you.

> 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 think that Octave should have got a new function:
It must execute some command and this function must not be listed in history.
Example:
nohistory('whos') <-- Neither nohistory nor whos are listed in history.

IDEs can use this function to do all suggested functionalities listed before.

Bye


>
> 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
>

2009/1/23, John Swensen <address@hidden>:
>
> 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.
>>
>>