Mercurial > jwe > qt-gui-with-push-parser
annotate NOTES @ 3:52c033864347
add build instructions to NOTES file
| author | John W. Eaton <jwe@octave.org> |
|---|---|
| date | Wed, 22 May 2019 16:21:06 -0400 |
| parents | dff751fb985c |
| children | 822a2fe5bb51 |
| rev | line source |
|---|---|
|
3
52c033864347
add build instructions to NOTES file
John W. Eaton <jwe@octave.org>
parents:
0
diff
changeset
|
1 To build: |
|
52c033864347
add build instructions to NOTES file
John W. Eaton <jwe@octave.org>
parents:
0
diff
changeset
|
2 |
|
52c033864347
add build instructions to NOTES file
John W. Eaton <jwe@octave.org>
parents:
0
diff
changeset
|
3 qmake calc.pro |
|
52c033864347
add build instructions to NOTES file
John W. Eaton <jwe@octave.org>
parents:
0
diff
changeset
|
4 make |
|
52c033864347
add build instructions to NOTES file
John W. Eaton <jwe@octave.org>
parents:
0
diff
changeset
|
5 |
| 0 | 6 Current terminal widget: |
| 7 | |
| 8 * Run Octave in a separate thread. On unixy, interact through pty. | |
| 9 On Windows systems, use hidden console and mirror contents in Qt | |
| 10 widget. | |
| 11 | |
| 12 Octave interpreter sees input directly, same as for normal | |
| 13 terminal application. Good, because no change in the way Octave | |
| 14 accepts and parses input. Bad because GUI is not in control of | |
| 15 input and must arrange to communicate across threads. | |
| 16 | |
| 17 Terminal window can (in theory) be used to run other applications | |
| 18 started from the system command (for example). This feature works | |
| 19 well enough for us to use less running as a separate process to | |
| 20 handle paging output, but it doesn't work for all applications. | |
| 21 For example, I am not able to run editors like Emacs or vi in the | |
| 22 GUI terminal window. | |
| 23 | |
| 24 To make less work as the pager on Unixy systems, the Octave must | |
| 25 fork, call setsid in the child to detach from the controlling | |
| 26 terminal, and then exec the GUI. | |
| 27 | |
| 28 GUI must deal with threads when communicating with the | |
| 29 interpreter. | |
| 30 | |
| 31 Proposal: | |
| 32 | |
| 33 * GUI terminal widget is in control of input. | |
| 34 | |
| 35 Use callback interface for readline to handle command line | |
| 36 editing. | |
| 37 | |
| 38 Use push parser to parse lines as they become available. Push | |
| 39 parser will return status of parse, either complete or needing | |
| 40 more input. | |
| 41 | |
| 42 Uses the following readline callbacks to manage input and update | |
| 43 the display. We may need more in the future to handle other | |
| 44 features. | |
| 45 | |
| 46 rl_getc_function | |
| 47 rl_redisplay_function | |
| 48 rl_completion_display_matches_hook | |
| 49 | |
| 50 rl_prep_term_function (do nothing) | |
| 51 rl_deprep_term_function (do nothing) | |
| 52 | |
| 53 Call rl_callback_handler_install to setup readlines | |
| 54 callback mode. This sets the initial prompt and provides a pointer | |
| 55 to a function that readline should call when a complete line of | |
| 56 input is available. | |
| 57 | |
| 58 Call rl_callback_read_char when a character is available for | |
| 59 readline to handle. We currently store the character to read in a | |
| 60 global value, then rl_get_function returns that character to | |
| 61 readline. | |
| 62 | |
| 63 Call rl_callback_handler_remove when shutting down. | |
| 64 | |
| 65 To avoid global variables, it would be helpful if we could use | |
| 66 lambda functions/functors as callbacks instead of plain C function | |
| 67 pointers. | |
| 68 | |
| 69 Questions: | |
| 70 | |
| 71 * With this arrangement, would the interpreter have to run in a | |
| 72 separtae thread? | |
| 73 | |
| 74 * Example parser currently computes results | |
| 75 immediately. How do we deal with parsing multiple expressions and | |
| 76 statements with this method? | |
| 77 | |
| 78 * Do we need text position markers to keep track of the prompt position | |
| 79 (beginning of current line) when inserting or clearing text? |