octave-maintainers
[Top][All Lists]
Advanced

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

Re:


From: Jacob Dawid
Subject: Re:
Date: Thu, 7 Apr 2011 19:11:49 +0200



2011/4/7 John Swensen <address@hidden>

On Apr 7, 2011, at 2:44 AM, Jacob Dawid wrote:

> Hello everybody,
>
> it turned that I was not aware of the problem with readline. However, it is quite questionable if putting a terminal emulation into a window can be a solution for a GUI - I don't think so. What Octave is missing is some way of communicating to it not using pipes or a terminal emulation, but that is not the case (I felt pipes were not the right thing, but I thought QtOctave was considered as the "right thing"). Maybe it is a better idea to integrate such a thing into Octave itself - and then building some GUI on top of it.
>

Jacob,
Thanks for starting to work on this. I think a lot of people have made attempts at an Octave IDE, but none have gained a lot of traction (mine included).  There are several issues that I have weighed as I have worked on OctaveDE over the last several years.  Some of them are listed below with some commentary (mostly personal opinion, but oft discussed elsewhere on the list)

1) The source code of Octave (and the language interpreter in particular) are integrated with the GNU Readline library.  The readline library provides a lot of nice features for a program that is a command line program. Readline also provides additional features that aren't currently used that would make it still "play nicely" with an IDE.  It has the ability to call a function with potential matches when someone tries to tab-complete a command, is deals with command history well, etc., etc.  In order to provide both IDE and terminal user's with the same user experience, I feel that putting a terminal emulation into a window is the exact right solution for an IDE.  Implementing a second method of interacting with the Octave interpreter that is used solely by the IDE would provide a different user experience for the two classes of users, and you would mostly be re-implementing things already provided by the GNU Readline library.

2) UI Toolkit: My original attempt at OctaveDE was based on GTK, GTKMM, and the VTE terminal emulator library.  This worked well for the Linux platform (and sometimes OSX), but was not a good solution for Windows. The GTK based solution also presented even greater problem when we started considering writing a GTK graphics backend for the new OpenGL plot renderer.  This made me investigate switching to QT and I have started that process.  Much of what I learned doing the GTK version of OctaveDE has transferred to the QT version quite nicely, in particular a class I wrote called octave_server that interacts with the guts of Octave only when Octave is in the idle even loop of the GNU Realine library.  Because Octave is not thread safe, interacting with Octave during this idle loop ensures that Octave is "doing nothing" while I send and retrieve data from the guts of Octave.

I'm sure there are other things I am forgetting to mention, but these were the two major issues.  I am going to continue and plug away at this for the foreseeable future.  The way it stands now, I think there are only two people working on the terminal emulator approach to an Octave IDE.  As you may have seen, Michael Goffioul is working on the Windows side of emulating a terminal and I have been working on the Linux/OSX/*NIX side of terminal emulation (I mostly just ripped the guts out of KDE Konsole and made it "KDE free").  I am also working on dockable widgets for command history, file browser, and variables information.  Two major things that will still need to be implemented are an editor with debugging support (my research made me think that QScinitilla will probably be the appropriate widget for that) and QT based OpenGL plotting window (this doesn't need to actually do any OpenGL drawing, just set up an OpenGL context and implement the Octave OpenGL backend interface).  If you are interested in working with us, I would be very appreciative.  I am not a QT expert at all and am learning QT as I go, so I maybe your help could accelerate things greatly.

John Swensen


John,

I had to think a bit about it, but I share your opinion now. During the day I have merged and refactored qtermwidget into a Qt-based GUI application, see my progress here:

https://github.com/jacobdawid/Quint

I am mostly doing Qt, so I think I could help you here to make some fast progress. I also have some experience with using OpenGL under Qt. At first I think we should boil down the code as much as possible, then see what's left over and then restructure it.

Jacob Dawid


--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .


reply via email to

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