Re: Yet another GUI releated thought

[Michael Goffioul]

On Thu, May 8, 2008 at 9:56 PM, Søren Hauberg <address@hidden> wrote:
> tor, 08 05 2008 kl. 12:15 -0400, skrev John W. Eaton:
>
> > If the GUI runs in a separate thread and Octave is not thread safe,
>  > then how do you make the GUI responsive while Octave is off doing some
>  > calculation?
>
>  What would you want a GUI to do while Octave is calculating? Start
>  another parallel calculation? The GUI just needs to know that it Octave
>  is busy, such that it doesn't start any new calculations.

To answer John's question first, the GUI would still be responsive
as long as nothing is required from the octave kernel. For instance,
trying to execute a callback (which are executed synchronously
with octave) would just freeze. But things like editing a file would
still work.

>  > Right, so you want to reimplement all the features of GNU readline in
>  > your GUI::readline function?
>
>  Tab-completion is easy as that is implemented by Octave anyway. History
>  searching might be a bit more work. GNU readline also implements all
>  sorts of keyboard shortcuts (Ctrl-k deletes the rest of the current
>  line, etc), which all would have to be reimplemented. But thoughts on
>  this is simply, to not reimplement this -- people using a GUI would just
>  loose some functionality (the most commonly used operations could
>  obviously by implemented, but an entire clone of readline, would be
>  silly).
>   The way I see it, if a GUI is simply a terminal with some extra stuff
>  around it (like the Matlab one), then I couldn't care less. However,
>  having the graphical capabilities opens up some new possibilities. Tab
>  completions and history searches could be displayed in drop-down menus
>  (is that the name?). Perhaps help texts could be displayed in HTML when
>  the user types 'help function_name'. But things like that really
>  requires that we don't use a terminal as the input -- it requires
>  something more general. The approach I suggested allows such things. It
>  would be quite some work, but at least it would be possible...

IMO the terminal emulation is the easiest way to go, because you
don't have to re-implement readline capabilities. Everything is already
there. And you can focus on other things like file editing, debugging
capabilities or graphics backend integration (that's what I mean by
GUI). We are so missing man-power that I wouldn't go that way to
for the time being (this could be added later on).

Just for the record, I personally don't find the drop-down menu of
Matlab for tab-completion very convenient. Let's say you have
100 possibilities, the drop-down menu shows you about 5 of them,
while the readline way shows you all of them. Having clickable
item in the command window (like for the "See also" items) would
indeed be interesting, although I never use it. This is something
that (I think) is possible with VTE. For more advanced documentation,
I would go for a separate HTML-based help browser.

These are only my feelings about the subject.

Michael.