Re: Terminal emulation in Octave GUI

[John Swensen]

On Apr 7, 2011, at 12:52 PM, John W. Eaton wrote:

> On  7-Apr-2011, Jordi Gutiérrez Hermoso wrote:
> 
> | On 7 April 2011 01:44, Jacob Dawid <address@hidden> wrote:
> | > 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.
> | 
> | I think you simply are envisioning a limited terminal. I don't know of
> | a reason why we can't have an Octave terminal in a GUI with readline
> | and not build other bells and whistles on top of it, like syntax
> | highlighting or pop-up completion menus. What I do think is rather
> | silly is to reimplement parts of readline like tab completion or
> | history search.
> 
> Since this seems to be quite a sticking point for GUIs, I'm willing to
> reconsider.
> 
> It seems to me the real question is about who should be handling
> events.  People who write GUIs think that the GUI should be the one
> handling all events.  That's counter to what normally happens for a
> command-line application, where it is normally waiting to read input
> from the terminal.  GNU readline allows functions to be called
> periodically while it is waiting for input, so it is possible for it
> to handle events while waiting for input, but people who write GUIs
> still don't like this very much because it is not the normal way they
> think about handling events.
> 
> I spent some time thinking about how to properly merge readline with a
> GUI by separating the parts that do terminal handling and redisplay
> from the parts that just manage the state of the current line, and how
> the normal usage of calling readline and expecting it to get input
> needs to be inverted so that the GUI is gathering input and passing it
> to readline one character at a time, only to discover that there is
> apparently already a way to do this job:
> 
>  http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC41
> 
>  2.4.12 Alternate Interface
>  --------------------------
> 
>  An alternate interface is available to plain `readline()'.  Some
>  applications need to interleave keyboard I/O with file, device, or
>  window system I/O, typically by using a main loop to `select()' on
>  various file descriptors.  To accomodate this need, readline can also
>  be invoked as a `callback' function from an event loop.  There are
>  functions available to make this easy.
> 
>   -- Function: void rl_callback_handler_install (const char *prompt,
>            rl_vcpfunc_t *lhandler)
>       Set up the terminal for readline I/O and display the initial
>       expanded value of PROMPT.  Save the value of LHANDLER to use as a
>       function to call when a complete line of input has been entered.
>       The function takes the text of the line as an argument.
> 
>   -- Function: void rl_callback_read_char (void)
>       Whenever an application determines that keyboard input is
>       available, it should call `rl_callback_read_char()', which will
>       read the next character from the current input source.  If that
>       character completes the line, `rl_callback_read_char' will invoke
>       the LHANDLER function saved by `rl_callback_handler_install' to
>       process the line.  Before calling the LHANDLER function, the
>       terminal settings are reset to the values they had before calling
>       `rl_callback_handler_install'.  If the LHANDLER function returns,
>       the terminal settings are modified for Readline's use again.
>       `EOF' is  indicated by calling LHANDLER with a `NULL' line.
> 
>   -- Function: void rl_callback_handler_remove (void)
>       Restore the terminal to its initial state and remove the line
>       handler.  This may be called from within a callback as well as
>       independently.  If the LHANDLER installed by
>       `rl_callback_handler_install' does not exit the program, either
>       this function or the function referred to by the value of
>       `rl_deprep_term_function' should be called before the program
>       exits to reset the terminal settings.
> 
> Using this interface in a GUI text box will probably also require
> writing a custom redisplay function because the text box will
> presumably not be something known to termcap.  So when readline needs
> to delete characters from the text box, or display a new line from the
> history list that replaces the current line, how is that supposed to
> happen in the context of a GUI text box?  A custom function would
> probably be needed.
> 
> Would someone who knows GUIs like to take a stab at hooking up a GUI
> text box (or other) widget with readline using the callback interface
> to demonstrate how this can be done?
> 
> jwe

Just to give my $0.02, I still think there is nothing wrong with the "Octave in 
a terminal emulator widget" solution. Is a pop-up box of the possible 
completions really the only thing in an IDE that people think that GNU Readline 
is prohibiting?  I think this is easily resolved by having octave store the 
results of rl_completion_matches() and sending them to the UI via the 
octave_server class.  After someone has invoked the tab completion mechanism of 
Readline, it goes back to the idle loop (if I remember correctly).  This mean 
that it would take about 1/20th of a second for the results of 
rl_completion_matches() to be sent back to the IDE and then displayed.  I don't 
think this is unreasonable.

As I mentioned in my last email to Jacob, I don't think that implementing a 
second interface (be it through the Readline alternative function callbacks or 
something altogether different) will provide a different user experience to IDE 
vs command line users.  I think sometime the natural progression is for users 
to move from IDE to command line and we would get a whole slew of other 
requests to make the command line more like the IDE.  I think it is better to 
head those type of things off now and make them as Jordi said, the same 
Readline interface for both with some bells and whistles on top of the IDE 
interface.

I think that the combination of Michael Goffioul's new QT replcation of the 
console2 solution for Windows, the QT terminal emulator widget for all others, 
and a switch to QT as the UI toolkit solves most of the problems that had made 
the GTK octavede so frustrating to work on:
1) Cross platform was just a dream and there are half a handful of people on 
planet Earth (Michael Goffioul being one of them) that could actually get all 
the dependencies to build on Windows
2) OpenGL with GTK on several platforms was excruciating to get to build and 
had quirks
3) I think more people know QT and the documentation is great

John Swensen