Re: rethinking interpreter <-> gui interaction

[Daniel J Sebald]

On 7/2/19 2:19 AM, Daniel J Sebald wrote:
> On 7/2/19 12:55 AM, John W. Eaton wrote:
> > On 7/1/19 11:57 PM, Daniel J Sebald wrote:
> > > On 7/1/19 2:47 PM, John W. Eaton wrote:
[snip]
> > Yes, I agree that it should be possible to do something like editing 
> > files as that doesn't generally require the interpreter to perform any 
> > action.  But what should happen if the GUI asks the interpreter to 
> > perform some action when it is already busy executing some other code? 
> > At what point is it safe for the interpreter to check the command 
> > queue and call other functions?
>
> I don't know.  Depends on the amount of sophistication you have in mind. 
>   The GUI can put more commands in the queue.  But a "break" routine 
> could work that way.  How callbacks might be mixed in there is also a 
> question.

Inquiring for information would be a simple entry into the queue if the 
GUI is interested in maintaining sequential commands.  That's easy.

But if you are wondering of how one would do, say, periodically updating 
the GUI (e.g., updating the variable display), perhaps a pause(0) would 
make a good place to update the GUI.  It might be easy to devise a 
"hidden" command scheme, i.e., one which the GUI issues but doesn't show 
up in the user's console or command history.  For example, the variable 
editor displays "myvar" which is a big matrix in which only 
myvar(589:602,345:353) are visible on the screen, then perhaps a hidden

  pause(0);
  ov = myvar(589:602,345:353);

would do.  ???

Dan