[Cuis-dev] hole in my Morphic knowledge

Mariano Montone marianomontone at gmail.com
Sat Aug 17 16:22:31 PDT 2024


El 15/8/24 a las 10:34, Mark Volkmann via Cuis-dev escribió:
> I was somewhat surprised to learn that LayoutMorph does not implement 
> a drawOn: method that sends #drawOn: to each of its submorphs. What is 
> it that triggers the submorphs to be drawn? I had assumed that any 
> morph can have submorphs, but most morphs (like LabelMorph) do not 
> draw their submorphs. Now I'm questioning that assumption.

There's an Erudite book which is not up-to-date. Feature require: 
'MorphicBook'.

It has a section on the UI loop:

"The UI Loop

At the heart of every interactive user interface framework lies the 
modern equivalent of the read-evaluate-print loop of the earliest 
interactive computer systems. However, in this modern version, "read" 
processes events instead of characters and "print" performs drawing 
operations to update a graphical display instead of outputting text. 
Morphic's version of this loop adds two additional steps to provide 
hooks for liveness and automatic layout:

do forever:
     process inputs
     send step to all active morphs
     update morph layouts
     update the display

Sometimes, none of these steps will have anything to do; there are no 
events to process, no morph that needs to be stepped, no layout updates, 
and no display updates. In such cases, morphic sleeps for a few 
milliseconds so that it doesn't hog the CPU when it's idle."

So, as you say, morphs dont' redraw their submorphs, the UI loop does 
it. LayoutMorph doesn't need a drawOn: method, as it has nothing to draw 
on a canvas, just get its submorphs positions right. Then the UI loop is 
in charge of triggering re-layout and redisplays of the "dirty" morphs. 
Also, LabelMorph doesn't have any submorphs, does it?


      Mariano



More information about the Cuis-dev mailing list