[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: Tue, 2 Jul 2019 02:19:29 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1

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.


reply via email to

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