* An area for the main command window that presents the Octave
prompt and displays the output from commands, just as you
currently see when running Octave in a terminal window.
The command line in this window must have GNU readline
command-line editing. If this can't be accomplished using a
terminal widget for the GUI toolkit that we choose to use, then
I've previously shown how we can get the same functionality
without a terminal widget (though there may be some problems yet
to be solved regarding what to do about the pager and other
external programs that expect to run inside a terminal). See the
following thread for more information:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-January/026739.html
Works.
* An area to display command history. It should be possible to
select and paste previous commands from the history window into
the command window.
Works.
* An area to display the contents of the current workspace. It
should be possible to display the contents of variables from this
list.
Works.
* Octave's doc command should display a formatted version of the
manual in a separate window. It is essential that this window be
visible simultaneously with the command window. We should not
use a tabbed interface for this feature. It should be possible to
choose which program is used to browse the documentation.
Works. You can either choose to have it tabbed or aligned parallel - which is also true for editor windows. The default at startup is the tabbed mode, probably a mistake I make, because now people seem to think it's all tabbed and needs to be replaced.
* When there is an error running an Octave script, an editor should
pop up and place the cursor at the line of the error.
Does not work yet.
* You should be able to interact with the debugger through the
editor.
Does not work yet.
* It is absolutely essential that the choice of editor is
configurable. It must be possible to use Emacs for this purpose.
Works.
* The windows used to display the OpenGL-based graphics must use the
same GUI toolkit that we use for the rest of the IDE.
Not implemented yet.
* Functions like uigetfile should use the same GUI toolkit that we
use for the IDE.
I can't comment on this, but I assume it is not implemented yet.
The Octave IDE will be used by novices. It is NOT the place for UI
innovation. We should use GUI/IDE features that are proven, familiar,
and easy to work with. We do not need dockable widgets. The ability
to change the relative sizes of the command, workspace, and history
windows would be useful, but we do not need to be able to rearrange
their locations within the main window. Tabbed interfaces will not be
used. Octave's IDE does not need a built-in IRC client, and will
not include one.
The IRC Client has already been moved to the help menu. I would agree if I knew how to start an external IRC Client - then it does not make sense to have one built-in.
Since people seem to like it, following the design of "GUI Octave"
makes sense to me. But it is not necessary to include every feature
of that interface in the first version of Octave's IDE. It would be
far better to have just the features above working reliably than to
have many more features that are only partially implemented or buggy.
Comments?
jwe
- modify variables graphically (ie. matrices in a table, strings in line edit dialogs)
- debugging with the built-in editor, setting breakpoints etc.