[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Terminal emulation in Octave GUI
From: |
John Swensen |
Subject: |
Re: Terminal emulation in Octave GUI |
Date: |
Thu, 7 Apr 2011 13:09:44 -0400 |
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