octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI [was: Re: Possible (summer of code) projects for Octave)


From: John Swensen
Subject: Re: GUI [was: Re: Possible (summer of code) projects for Octave)
Date: Thu, 6 Jan 2011 10:41:38 -0500

On Jan 6, 2011, at 8:51 AM, Søren Hauberg wrote:

> tor, 06 01 2011 kl. 08:06 -0500, skrev John Swensen:
>> On Jan 5, 2011, at 11:02 PM, Jordi Gutiérrez Hermoso wrote:
>> 
>>> On 4 January 2011 21:47, Thomas Yengst <address@hidden> wrote:
>>>> Not so much a GUI, but what Octave needs is a Workspace (in Matlab's
>>>> sense) that shows variables, dimensions, bytes, etc.
>>> 
>>> The current contenders for the GUI throne already do that.
>>> 
>>> I think I agree with Søren's ideas, though. If we are to properly
>>> integrate something like OctaveDE or QtOctave into Octave, we first
>>> need to implement some C++ functions in core. I've added it to the
>>> wishlist:
>>> 
>>>    http://wiki.octave.org/wiki.pl?Projects
>>> 
>>> - Jordi G. H.
>> 
>> If you look at the source code repository for OctaveDE, there is
>> already an attempt to do that.  It is a class called Octave server.
>> It is a class that hooks into the idle event loop for readline and
>> does transactions with Octave during the idle event loop.  This
>> *should* be inherently thread safe, as Octave is doing nothing while
>> the readline idle event loop is running. I proposed this be included
>> in the Octave sources a while back, but I don't think there was much
>> interest.
>> 
>> There are some things that an IDE can place a request to the
>> octave_server and the data will be retrieved on the next call to the
>> idle event loop (e.g. the contents of a specific variable, placing or
>> clearing breakpoints, etc), there are some things that get requested
>> every time it runs (e.g. any additions to the command history or the
>> names, types, and sizes of the variables in scope).  The octave_server
>> maintains a copy of these items until they have been retrieved by the
>> IDE and uses mutexes to ensure thread safety of the IDE and readline
>> idle event loop accessing octave_server.
>> 
>> The octave_server has absolutely no dependence on OctaveDE and could
>> trivially be pulled into any other project (IDE or no) that wishes to
>> request/retrieve this kind of data from Octave in a threadsafe manner.
> 
> From what I understood this class was able to retrieve data (such as
> variable information, etc.) from Octave, but it was not used for
> evaluating code, i.e. you cannot do
> 
>  octave_server O;
>  O.eval ("for k = 1:10, disp (k); endfor");
> 
> Is that correct? I was under the impression that you actually need to
> embed a terminal widget (VTK, ...) in the GUI in order to provide the
> user with some means of interaction.
> 
> I would like to see member functions that would allow me to do something
> like
> 
>  octave_server O;
>  bool A = O.is_complete ("k = 1;"); // returns true
>  bool B = O.is_complete ("for n = 1:10"); // returns false
>  O.eval ("k = 1");
> 
> Especially the ability to determine of a line of code is complete seems
> to be of particular interest to me. Without this, it becomes really hard
> to provide a GUI that does not depend on a terminal widget.
> 
> Søren
> 


You are right that it doesn't allow for evaluation of commands through the 
server. However, albeit not in the way you might expect, this is quite easy to 
do with the current setup (assuming a terminal emulator).  OctaveDE currently 
allows you to select a command (or commands) in the command history, right 
click, and execute the set of commands.  It should be easy enough to detect 
when Octave is back at the readline idle event loop do ascertain when the 
commands are completed.  Although not built into the editor portion yet, a 
similar thing could be done for highlighting sections of code in the editor and 
evaluating, or for duplicating the "cell" behavior of the Matlab editor (maybe 
that is patended, however, and we can't duplicate).

As you noted, however, this requires a terminal emulator unless we want to rip 
out readline and re-implement its functionality (something that I personally 
think is a bad idea).  

John Swensen






reply via email to

[Prev in Thread] Current Thread [Next in Thread]