[Top][All Lists]

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

Re: rethinking interpreter <-> gui interaction

From: John W. Eaton
Subject: Re: rethinking interpreter <-> gui interaction
Date: Tue, 2 Jul 2019 00:55:46 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1

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).

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?

In the patch, that is the key, dynamic connections to a "queue" result. There currently is a queuing mechanism for commands, say "cd" or "pwd". The patch extends that idea to include a broadcaster.  In the latter command, some information is returned in an octave_value class.  In the GUI, the object that wants the information puts the command "pwd" in the queue and dynamically makes a connection to the queue result or "broadcast".  The queue also keeps a record of the requesting object's ID (this) so that on the return trip all the objects that may be connected to the broadcaster can compare their "this" against the ID to recognize, "Hey, that's my data!".  Once the GUI has its data, it can choose to disconnect so that the broadcaster doesn't get too many subscribers--or whatever analogy one wants to use.

OK, I will look again at the patch. I probably promised to do that in the past, maybe more than once. But I don't think I really understood threads and Qt signals and slots well enough until now to be able to properly evaluate it.



reply via email to

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