Re: rethinking interpreter <-> gui interaction

[Daniel J Sebald]

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:
>
> > There shouldn't be a need to make either side of the link suspend and 
> > wait on anything.
>
> Don't functions like inputdlg have to wait for a result?  As I 
> understand it, function like that ask the GUI to create a dialog and 
> then they can't return until the dialog is closed and a result is 
> returned (or an error is thrown).

I suppose so; the input dialog would be used in a script sequence so 
couldn't not pause.  More generally perhaps there should be a modal 
setting.  Maybe then dialogs can be used to build GUIs as well, i.e., 
have a callback function.  Isn't that how many of these menu items work? 
 But the core processing engine wouldn't necessarily have to sit idle, 
just not advance the script until a callback arrives???  If Qt puts the 
inputdlg in modal mode, then there is no way any other GUI object could 
issue some other callback.


> > To make the GUI wait feels unnatural.  Instead, you'd like to allow 
> > the user to edit files and whatnot when a long worker process is running.
>
> 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.

Dan