> On 2023-02-28, at 5:39 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 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.


That's not entirely correct so far as I can see, and certainly not what I remember. Mind you, it is about 20 years since I used an MVC project for anything.

In MVC-land there is a *new* UI process created each time a window is activated; try opening a process browser and setting it to autoupdate, then opening some general windows and moving around them.


> 
> Obviously there are historical reasons why the two frameworks were
> done in these two different ways, but to me this seems to me to be
> a rather fundamental difference in approach.
> 
> That leads me to wonder what a morphic style of interface might look
> like if the morphs were not directly dependent on a single UI thread.
> 
> Maybe this is what Andreas was addressing in Tweak? I really do not
> know. But it seems to me that both MVC and Morphic are wonderful
> frameworks, while each carries some baggage from the era in which
> it was developed.

We used Tweak in the Sophie project and it was ... painful. Very different and a total nightmare to debug in, which really made life much less pleasant. 

> 
> Stephen Travis Pope is trying to encourage some discussion here.
> I don't think that he literally wants to go back to the original
> MVC framework, but if we could have some kind of "MVC" that looks
> and behaves like Morphic, and that maintains a better separation
> of models, views, and controllers, that might be a Very Good Thing.
> 
> I also suspect that if separation of model, view, and controller
> is a good thing, then getting rid of our Morphic dependency on a
> single UI thread may be a prerequisite. Without that, the concept
> of a "controller" does not make much sense.

One of my then and always objections to morphic was the conflation of everything into one lump; it struck me as pure laziness. It was, I think, inherited from the original Self version. Splitting out controllers allowed for different handling of inputs for the same views and models, splitting out views allowed for differing rendering of the same models. I *don't* think that requires any change to how the morphic world uses a single process though. The big problem with actually having separate processes for each window/widget/morph include the aforementioned debugging horror and the need to have resource locking absolutely everywhere. That tends to be expensive.

Note that we actually do have separate models in morphic as well, for some but not all cases. Look at the hierarchy for Model.

Where morphic has some wins is the model of a morph requesting information about whether it needs to update rather than the older update/changed model where some application model says "I changed my wibble!" and a storm of changed/update messages blasts through the system. The practical problem with that was always in making sure all the implementations coordinate well. It is terribly easy to end up with cycles that don't stop, duelling counter-updates and so on. The morphic approach avoids that at the (non-trivial) cost of checking regularly with the stepping mechanism. Ironically it (kinda) goes back to the old co-operative multitasking idiom of RISC OS, mac OS 9 and Windows 3 ;-)

But - it is simpler to explain and program and handle. We must note that the dependency is all still there in morphic as well if you want to use it. It manages to simplify even that though, by simply gathering changed notifications and making them kill the bounding rectangle, which then acts as a trigger to redraw and thereby update.

Having worked for several years with the great Mad Dog Leibs when I was managing the dept. at parcplace, building VisualWorks 1 and 2, I can say with some fervour that I hated ValueHolder then and I do now. I think it was a terrible idea that resulted in a catastrophic mental disconnect between components and the model logic. When you use a name in a way that puts it everywhere it becomes near meaningless and makes it almost impossible to follow logic through it. I had to try to unravel some recent VW code a couple of years ago and I deeply disapprove of what it has become.

If anyone wants a UI builder, well there are several in Squeak world. Try looking for vivide for example, or perhaps maui for a quite different approach.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Never test for an error condition you don't know how to handle.