[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