Deferred UI messages in MVC can be deferred for a really long time

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deferred UI messages in MVC can be deferred for a really long time

Christoph Thiede

Hi all!


Quick experiment:

Open an MVC project, open a Workspace in it, and do it:

Project current addDeferredUIMessage: [self inform: #foo]


In Morphic, this produces a dialog message "nearly immediately". But in MVC, apparently, I can sit there for hours and wait for the dialog and it will not pop up before I move my cursor out of the Workspace, giving the world controller (is this the correct naming?) a chance to process the deferred UI messages.


Is this desired behavior? If not, has someone already considered a chain of responsibility pattern for every controller that could allow its parent controller to take some actions (such as deferred UI messages or also handling system events like a VM window close request)? Or would this be contrary to the MVC idea? :-)


Best,

Christoph



Reply | Threaded
Open this post in threaded view
|

Re: Deferred UI messages in MVC can be deferred for a really long time

David T. Lewis
On Wed, Sep 16, 2020 at 06:47:19PM +0000, Thiede, Christoph wrote:

> Hi all!
>
>
> Quick experiment:
>
> Open an MVC project, open a Workspace in it, and do it:
>
> Project current addDeferredUIMessage: [self inform: #foo]
>
>
> In Morphic, this produces a dialog message "nearly immediately". But in MVC, apparently, I can sit there for hours and wait for the dialog and it will not pop up before I move my cursor out of the Workspace, giving the world controller (is this the correct naming?) a chance to process the deferred UI messages.
>
>
> Is this desired behavior? If not, has someone already considered a chain of responsibility pattern for every controller that could allow its parent controller to take some actions (such as deferred UI messages or also handling system events like a VM window close request)? Or would this be contrary to the MVC idea? :-)
>
>

Yes that is how it works. The deferred action queue is handled
when transferring control from one controller to another (in
Controller>>controlActivity).

MVC is not as directly interactive as Morphic, and things seem
to "happen" when your mouse movement causes a different controller
to become active.

When active, each controller has its own process. There is no such
thing as a UI process that controls the world as in Morphic. Instead,
Project current world is a ControlManager, which coordinates the
various controllers and their processes.

The deferred action queue was never part of the original MVC, so if
you can think of a way to make it more responsive, no one will take
any offence :-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Deferred UI messages in MVC can be deferred for a really long time

marcel.taeumel
Hi Christoph, hi Dave,

fixed in ST80-mt.258

Best,
Marcel

Am 17.09.2020 02:16:31 schrieb David T. Lewis <[hidden email]>:

On Wed, Sep 16, 2020 at 06:47:19PM +0000, Thiede, Christoph wrote:
> Hi all!
>
>
> Quick experiment:
>
> Open an MVC project, open a Workspace in it, and do it:
>
> Project current addDeferredUIMessage: [self inform: #foo]
>
>
> In Morphic, this produces a dialog message "nearly immediately". But in MVC, apparently, I can sit there for hours and wait for the dialog and it will not pop up before I move my cursor out of the Workspace, giving the world controller (is this the correct naming?) a chance to process the deferred UI messages.
>
>
> Is this desired behavior? If not, has someone already considered a chain of responsibility pattern for every controller that could allow its parent controller to take some actions (such as deferred UI messages or also handling system events like a VM window close request)? Or would this be contrary to the MVC idea? :-)
>
>

Yes that is how it works. The deferred action queue is handled
when transferring control from one controller to another (in
Controller>>controlActivity).

MVC is not as directly interactive as Morphic, and things seem
to "happen" when your mouse movement causes a different controller
to become active.

When active, each controller has its own process. There is no such
thing as a UI process that controls the world as in Morphic. Instead,
Project current world is a ControlManager, which coordinates the
various controllers and their processes.

The deferred action queue was never part of the original MVC, so if
you can think of a way to make it more responsive, no one will take
any offence :-)

Dave