[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rethinking interpreter <-> gui interaction

From: Daniel J Sebald
Subject: Re: rethinking interpreter <-> gui interaction
Date: Thu, 4 Jul 2019 11:38:44 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1

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:
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

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

would do.  ???


reply via email to

[Prev in Thread] Current Thread [Next in Thread]