octave-maintainers
[Top][All Lists]
Advanced

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

Re: wxOctave???


From: John Swensen
Subject: Re: wxOctave???
Date: Thu, 14 Jun 2007 09:23:27 -0400
User-agent: Thunderbird 2.0a1 (X11/20060807)

John W. Eaton wrote:
On 14-Jun-2007, Shai Ayal wrote:

| If you mean an integrated development environment (IDE), have a look
| at octave-workshop
| http://www.math.mcgill.ca/loisel/octave-workshop/
| which has the same aims but is currently unmaintained. Maybe you can take it 
up?

I think the current design of these kinds of tools which attempt to
tack on a GUI to the Octave interpreter in which the GUI handles all
input and then tries to use something like eval() to pass lines to the
interpreter is fundamentally flawed.  For example, to get multi-line
input working correctly, you have to make the GUI input *the* input
method for the parser.  You can't just grab lines and pass them to
eval().  Knowing what constitutes a complete statement requires a
parser, and I don't think it makes sense to write a second parser for
the GUI that tries to decide when a complete statement is available so
that it can be passed to eval.  The Octave parser already knows how to
do this, you just need to hook into it in the appropriate way.

I think the GUI needs to be integrated with Octave so that
the Octave event loop is in control of all GUI events and keyboard
input.  One way to acheive this without too much effort is to use
something like the VteTerminal widget that is an add-on for Gtk.  I
don't know whether something similar exists for WxWidgets, or if
anything like this can even be made to work reliably on a Windows
system.  If not, then I think it will require more work to get it
right, but it should still be possible.  Unfortunately, it may mean
writing (or borrowing) large chunks of code that can emulate a
terminal so that readline can be used.

Some additional thoughts on Octave and GUIs, including some sample
VteTerminal code can be found here:

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

I think the patch that is mentioned in the comments of the code I
posted has now been accepted into the VteTerminal sources, so it may
no longer be necessary.  See:

  http://www.nabble.com/Patches-to-vte-accepted-tf1507584.html#a4089052

and also note that John Swensen was working on a similar project but I
don't think he has posted here in a while.

jwe

I haven't worked a lot on it in quite a while (I had these delusions that once I returned to grad school I would have a little more time for side projects...boy was I wrong). My implementation, however, does use the VTE concept for the command window and then I just accessed the symbol table, the command history, etc. through functions provided by octave (since my program was running in the same memory space). Not very thread safe, but I just made sure the interpreter wasn't running before calling any Octave provided functions.

I did have a few complaints about my own implementation though.
1) Far too many dependencies on other libraries. I use GTKMM (a C++ wrapper around GTK) because I feel much more comfortable with UI programming with objects since the only other UI programming I ever did was on Java. Since I was trying to include a full editor/debugger window, it depends on GtkSourceView, which in turn depends on a whole slew of other stuff. 2) Since this was still a proof of concept, the code is organized horribly. While most of the functionality is in there, there needs to be a major redesign. Plus, I am not a UI designer by trade. 3) Some level of thread safety need to be included in Octave itself. My proposed method was to have octave push/pull a bunch of data to a threadsafe object whenever it returned to the regular prompt or the debug prompt.

For anyone who is still interested, I probably still work on it about an hour every 2 weeks and the code is available through Sourceforge at http://sourceforge.net/projects/octavede.

John Swensen


reply via email to

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