Re: GUI design

[John W. Eaton]

Jacob,

First, let me say that the current version of the IDE is much improved
and seems to work well, at least judging from the limited testing I've
done.  I think the appearance is nearly what we want.  The defaults
seem mostly good at this point.  I have just a few specific comments
below.

On 27-Mar-2012, Jacob Dawid wrote:

|     * 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.
|       [...]
| 
| 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.

How about starting with only the command window and making the
documentation browser a separate pop-up window that is accessible
through the "Help" menu item?

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

It's not.  We need to replace src/DLD_FUNTIONS/__init_fltk__.cc with a
Qt version to match your Qt-based IDE.

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

OK.  I think this should be made a separate program so that it will be
easier for users to invoke their favorite client through some script.
Shouldn't it be possible to start an external irc client program using
a call to "system".

|     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
| 
| From my point of view there are still three essential things to do:
| - fix crashes that are caused through thread-insafety

Yes, this must be done.  I don't know how you are doing things now,
but band-aids for Octave thread safety are probably not going to do
it.  I think you have to ensure that Octave is not called except when
it is safe to do so.  So you can queue events for Octave to process,
then let Octave handle them when it is safe to do so (like in the
readline idle loop) but you can't just call internals of Octave at any
time.

| - modify variables graphically (ie. matrices in a table, strings in
|   line edit dialogs)

This would be nice.  If it is easy to do, then great.  But I don't see
it as essential for the first release.  So if it is difficult then it
could certainly wait until later.

| - debugging with the built-in editor, setting breakpoints etc.

I think this is a fairly important feature, but again if it turns out
to be really difficult, it could probably wait.

jwe