Modal UI

In the process of my app's execution, it needs to put up a UI, and pause until the UI returns an object (only this piece of code needs to pause, the rest of the world can keep going).  I was thinking of using forks, but FillInTheBlankMorph seems to manually drive the world's doOneCycle while it waits (seems ugly and a little too controlling).

What would be the best way?

Thanks.
Sean

On 05.11.2010, at 23:18, Sean P. DeNigris wrote:

>
> In the process of my app's execution, it needs to put up a UI, and pause
> until the UI returns an object (only this piece of code needs to pause, the
> rest of the world can keep going).  I was thinking of using forks, but
> FillInTheBlankMorph seems to manually drive the world's doOneCycle while it
> waits (seems ugly and a little too controlling).
>
> What would be the best way?

Redesign your app so it does not have to pause but is event-driven (or possibly continuation-based). Then just lock the part that should not be interactive.

FillInTheBlank has to do that ugly doOneCycle because it was made to work with non-eventdriven programs.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Bert Freudenberg wrote

Redesign your app so it does not have to pause but is event-driven (or possibly continuation-based).

That sounds promising.  A little more detail to clarify.  At this point, the app could be driven through the API, and there may be no GUI (definitely for now, because I haven't designed the GUI, lol).  However, the app will need user information here to continue its work.  So...
* Events - would only be if I had a GUI before I opened this request, right?
* Continuations - I'm not so familiar with them (a little Seaside).  Are you saying to supply the GUI with a callback selector/block?

Thanks.

Sean

On 07.11.2010, at 16:39, Sean P. DeNigris wrote:

How would it get that info without a GUI?

>  So...
> * Events - would only be if I had a GUI before I opened this request, right?

Well, that's what I assumed, yes.

> * Continuations - I'm not so familiar with them (a little Seaside).  Are you
> saying to supply the GUI with a callback selector/block?

Exactly.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Continuations it is then.  Is there a big difference between passing a block vs. a receiver and selector.  The block way seems simpler and more flexible - any downside?

Sean

On 08.11.2010, at 16:51, Sean P. DeNigris wrote:

> Continuations it is then.  Is there a big difference between passing a block
> vs. a receiver and selector.  The block way seems simpler and more flexible
> - any downside?

Blocks are harder to debug, and dangerously powerful. In my designs I try to stay away from ever storing a block for later use.

You might substitute a MessageSend for the Block. Nicely explicit and simple.

- Bert -

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Bert Freudenberg wrote

You might substitute a MessageSend for the Block. Nicely explicit and simple.

Okay, thanks.  I'll try that.

Sean