[squeak-dev] GUI threads (was: Replacing or enhancing or supplementing Morphic)

Jakob Reschke jakres+squeak at gmail.com
Wed Mar 1 19:18:13 UTC 2023


Event-loop based UI development is usually a good strategy. It is how
Windows works at the foundations... I know that this will sound rather like
an argument against it for some people. ;-P

The question is whether it is convenient to program like that. All parts
involved must account for the asynchronicity. It may be more convenient to
just send a Smalltalk message rather than using addDeferredUiMessage: and
wrapping your intent in a block, but the code that comes after that line
looks different, too. Especially if you need a result/response to continue
your overall computation. You may be inclined to use Promises there, where
you would not do that otherwise, for example.

In my opinion right now it is more convenient to develop in a synchronous
manner in Squeak because the debugger in its current state is better suited
for that. It does not support you very well with Promises, deferred UI
messages, spawned processes and the like... And when some of the tools that
you are used to do not support you well anymore, it does not feel good.



Am Mi., 1. Mรคrz 2023 um 19:40 Uhr schrieb rabbit <rabbit at callistohouse.org>:

> Awesome! Jecel, Iโ€™m quite curious to hear your thoughts on eventual
> sending. EVERYBODIES thoughts, really. Is event-loop eventual sending a
> feasible style / function for UI development?
>
> ๐Ÿฐ
>
> โ€”
> Have a good one; keep it, light.
> Kindly, rabbit . .. โ€ฆ โ€˜โ€ฆ^,^ ๐Ÿ‡๐Ÿ‡๐Ÿ‡
>
> Sent from Callisto House mobile - Ganymede
> :: decentralized mobile homeless solutions ::
>
>
>
>
> On Wed, Mar 1, 2023 at 13:00, Jecel Assumpcao Jr <jecel at merlintec.com>
> wrote:
>
> David T. Lewis wrote on Tue, 28 Feb 2023 20:39:54 -0500
> > In MVC, each Controller has its own Process, and those processes are
> > scheduled when needed as windows are activated. In Morphic, there is
> > a single UI process.
>
> True, but misleading. Just like the VM has a single OS thread that it
> multiplexes between image level processes, the single Morphic thread
> pretends to run each morph in parallel at a known rate by repeated
> sending #step to them.
>
> Because we know that only when #step for one morph is finished that
> #step will be sent to the next morph, we have been programming as it
> morphs did not execute in parallel even though that is what the model
> was supposed to be. That is why we get in trouble when things happen
> outside of the GUI scheduler.
>
> In Self you have have more than one Morphic window and each gets its own
> GUI thread, but they are unlikely to share the same objects so we don't
> notice the problem. You can also have multiple windows in different
> machines viewing the same "world" and in that case they all share a
> single GUI thread.
>
> -- Jecel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230301/19b7bfc5/attachment.html>


More information about the Squeak-dev mailing list