Thoughts about a different approach to the GUI terminal widget

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts about a different approach to the GUI terminal widget

John W. Eaton
Administrator
Way back in January 2012, I posted the following message about changing
the terminal widget in the GUI to handle input differently.

 
http://lists.gnu.org/archive/html/octave-maintainers/2012-01/msg00416.html

I included a simple example written with gtkmm to illustrate the idea of
having the terminal widget in the GUI be in control of input and output
and feed lines of text to the interpreter.  To properly handle input
that spans multiple lines, a push parser is used instead of the current
pull parser.  It worked as an example, but was not much help for Octave
since we are using Qt.  So now I've reworked it using Qt and you can
find my sources here:

   http://hg.octave.org/jwe-qt-gui-with-push-parser

See the NOTES file for build instructions.  That file also contains the
following list of open questions that will need to be resolved if we are
going to attempt a switch.

   * With this arrangement, would the interpreter have to run in a
separate thread?  As the example shows, it's not absolutely necessary.
It could offer some advantages, but only if it is possible for the GUI
to do useful things while the interpreter is busy.

   * If the interpreter is not running in a separate thread but but the
graphics engine is, then what happens to graphics callbacks when the
parser is in the middle of parsing an expression?  Or is this not an
issue because separate parsers can be used even if there is only one
evaluator?  Could it ultimately be possible to have the evaluator
running in multiple threads?

   * If the interpreter does run in a separate thread, we still must
wait for it to calculate and return a result so we can synchronize input
and output.  Otherwise, we may print the next prompt before the output
from the previous expression is evaluated and printed.  You'll see this
behavior if you build the example program with
CALC_USE_INTERPRETER_THREAD defined.

   * The example parser currently also performs evaluations and computes
results immediately so it doesn't properly handle expression lists that
are split across multiple lines.  Octave wouldn't have this problem
because we already build a parse tree then execute it once it is complete.

   * Do we need text position markers to keep track of the prompt
position (beginning of current line) when inserting or clearing text?
This doesn't seem necessary in the current example, but it doesn't have
functions that can clear the screen or otherwise redraw prior output
that would cause the position of the cursor in the window to change.

   * The example program doesn't attempt handle multi-line prompts or
prompts with invisible characters (color specifications, for example).
Fixing that will make the redisplay function significantly more complex.
  See, for example, how complicated the default rl_redisplay function is
in the readline library.  Unless we actually write a terminal emulator
(like the current terminal widgets) then it is not possible to use
readline's rl_redisplay function directly.

   * We'll need to implement a pager ourselves, since "less" won't work
in this simplified terminal widget.

   * The system function may need to be modified so that external
programs that expect to be running in a terminal will continue to work
properly.  On Unixy systems, this job can be done with ptys.  I guess
Windows systems can use a hidden console?  But if these things are
required, are we more or less back to were we were before since we used
a pty and hidden console to implement the terminal widgets?  I believe
the Emacs start-process function must do similar things, so we might be
able to reuse that code.

   * If readline runs in the terminal widget, who owns the command-line
history?  Either way, if the GUI is in control of keyboard input, it
will need access to the history list and Octave will also need access
for the history functions.

Now that I have an almost working (if quite simplistic) example in Qt, I
will attempt to modify Octave to use this approach.  From that, I expect
many more questions to come up.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about a different approach to the GUI terminal widget

siko1056
On Wed, May 29, 2019 at 5:07 AM John W. Eaton <[hidden email]> wrote:

>
> Way back in January 2012, I posted the following message about changing
> the terminal widget in the GUI to handle input differently.
>
>
> http://lists.gnu.org/archive/html/octave-maintainers/2012-01/msg00416.html
>
> I included a simple example written with gtkmm to illustrate the idea of
> having the terminal widget in the GUI be in control of input and output
> and feed lines of text to the interpreter.  To properly handle input
> that spans multiple lines, a push parser is used instead of the current
> pull parser.  It worked as an example, but was not much help for Octave
> since we are using Qt.  So now I've reworked it using Qt and you can
> find my sources here:
>
>    http://hg.octave.org/jwe-qt-gui-with-push-parser
>
> See the NOTES file for build instructions.  That file also contains the
> following list of open questions that will need to be resolved if we are
> going to attempt a switch.
>
>    * With this arrangement, would the interpreter have to run in a
> separate thread?  As the example shows, it's not absolutely necessary.
> It could offer some advantages, but only if it is possible for the GUI
> to do useful things while the interpreter is busy.
>
>    * If the interpreter is not running in a separate thread but but the
> graphics engine is, then what happens to graphics callbacks when the
> parser is in the middle of parsing an expression?  Or is this not an
> issue because separate parsers can be used even if there is only one
> evaluator?  Could it ultimately be possible to have the evaluator
> running in multiple threads?
>
>    * If the interpreter does run in a separate thread, we still must
> wait for it to calculate and return a result so we can synchronize input
> and output.  Otherwise, we may print the next prompt before the output
> from the previous expression is evaluated and printed.  You'll see this
> behavior if you build the example program with
> CALC_USE_INTERPRETER_THREAD defined.
>
>    * The example parser currently also performs evaluations and computes
> results immediately so it doesn't properly handle expression lists that
> are split across multiple lines.  Octave wouldn't have this problem
> because we already build a parse tree then execute it once it is complete.
>
>    * Do we need text position markers to keep track of the prompt
> position (beginning of current line) when inserting or clearing text?
> This doesn't seem necessary in the current example, but it doesn't have
> functions that can clear the screen or otherwise redraw prior output
> that would cause the position of the cursor in the window to change.
>
>    * The example program doesn't attempt handle multi-line prompts or
> prompts with invisible characters (color specifications, for example).
> Fixing that will make the redisplay function significantly more complex.
>   See, for example, how complicated the default rl_redisplay function is
> in the readline library.  Unless we actually write a terminal emulator
> (like the current terminal widgets) then it is not possible to use
> readline's rl_redisplay function directly.
>
>    * We'll need to implement a pager ourselves, since "less" won't work
> in this simplified terminal widget.
>
>    * The system function may need to be modified so that external
> programs that expect to be running in a terminal will continue to work
> properly.  On Unixy systems, this job can be done with ptys.  I guess
> Windows systems can use a hidden console?  But if these things are
> required, are we more or less back to were we were before since we used
> a pty and hidden console to implement the terminal widgets?  I believe
> the Emacs start-process function must do similar things, so we might be
> able to reuse that code.
>
>    * If readline runs in the terminal widget, who owns the command-line
> history?  Either way, if the GUI is in control of keyboard input, it
> will need access to the history list and Octave will also need access
> for the history functions.
>
> Now that I have an almost working (if quite simplistic) example in Qt, I
> will attempt to modify Octave to use this approach.  From that, I expect
> many more questions to come up.
>
> jwe
>
There are so many items addressed in your email, I think we can manage
and discuss all your ideas better in the wiki:

   https://wiki.octave.org/GUI_terminal_widget

Do you agree?  Then I'll answer there and I keep my answer here short
and only attach a small patch to suggest colorful output =)

I think in your repo some file "calc.mk" is missing?  I have to run
the contained "Makefile" (includes calc.mk as well) to create
"parser.cc" manually, before I can apply the steps from NOTES.

Best,
Kai

new_terminal_widget_color.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about a different approach to the GUI terminal widget

John W. Eaton
Administrator
On 5/29/19 6:42 PM, Kai Torben Ohlhus wrote:

> There are so many items addressed in your email, I think we can manage
> and discuss all your ideas better in the wiki:
>
>     https://wiki.octave.org/GUI_terminal_widget
>
> Do you agree?

I know there are a lot of issues to think about.  I'm not sure whether a
wiki is best for discussion, but we can try it.

> I think in your repo some file "calc.mk" is missing?

The calc.mk file is not included because it is generated from calc.pro
by qmake.  The following works for me:

   qmake calc.pro
   make

If parser.cpp is missing when you run qmake you'll get a warning about
it, but it is safe to ignore.  There may be better ways to handle files
generated by bison with qmake but I wanted to keep things simple and
this worked well enough for me.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Thoughts about a different approach to the GUI terminal widget

siko1056
On Thu, May 30, 2019 at 1:05 AM John W. Eaton <[hidden email]> wrote:

>
> On 5/29/19 6:42 PM, Kai Torben Ohlhus wrote:
>
> > I think in your repo some file "calc.mk" is missing?
>
> The calc.mk file is not included because it is generated from calc.pro
> by qmake.  The following works for me:
>
>    qmake calc.pro
>    make
>
> If parser.cpp is missing when you run qmake you'll get a warning about
> it, but it is safe to ignore.  There may be better ways to handle files
> generated by bison with qmake but I wanted to keep things simple and
> this worked well enough for me.
>
> jwe
>

Now this works for me without trouble, too.  Maybe I did something
wrong at my first compilation... sorry for the noise.

Best,
Kai