Re: GUI work (was: Graphical help browser)

[Jordi Gutiérrez Hermoso]

Can we discuss GUI development for Octave in the Octave mailing list?
Could we sanction some GUI as an official part of Octave so that we
don't have 8 aborted GUI attempts scattered over the past decade?

I hope so.

Now, I got around to compiling OctaveDE, and hit a few snags:

   1) The configure script couldn't find my WebKit installation, so I
   had to change WebKitGtk to webkit-1.0 in configure.ac

   2) The #include directive assumes that <WebKit/webkit.h> is the
   location of this header file whereas in my Debian install it is in
   <webkit/webkit.h>, so I changed it in HelpWindow.h

   3) I needed to install Xapian and GLUT development packages
   but the configure script didn't check for them.

   4) There is some code under an HAVE_OCTAVE_300 macro that doesn't
   compile in server.cpp, so I #if 0'ed it.

They were all easy to fix, at least for Debian, cross-platform
compilation be damned. ;-) Now it seems to work. I might think of
moving it to CMake, because autotools compilation seems really arcane
to me, and I don't like having to learn four different macro languages
to accomplish one task.

I tried it out briefly... it looks nicer than I thought it would,
although the paging problem seems to persist here. It seems that
when Octave pages to less, then less doesn't bind the input, so the
Octave server gets stuck at this point (unless I did something wrong).

2008/11/27 John Swensen <address@hidden>:
> As for the worksheet interface, I am assuming you mean something like
> Mathematica or Maple where you can input a bunch of stuff, change some value
> in the middle, then re-evaluate the entire worksheet?

Well, there is more than that. You resolve the paging problem by
having the Octave output fit into reasonably-sized fields within the
worksheet interface. There is no longer a need to keep a command
history in a separate window, since the previous commands are in past
input fields. You could even fit graphical output into the worksheet
interface instead of opening separate windows, which always seemed to
me like e a mostly useless design choice of the Matlab GUI. It's just
an overall more complete integration and slightly useful of a GUI that
would even make me consider switching to it instead of Emacs (and if
we are using GTK+, I could even have Emacs-like keybindings as I do on
Firefox and Xchat and elsewhere by choosing the Emacs keybinding
theme).

> My intent has always been to make an imitation IDE to make it easier
> on new users.

New users just seem to be scared of white text on black backgrounds
and "DOS applications". I don't think we have to replicate the design
errors of the Matlab GUI in order to appease new users.

- Jordi G. H.