[Cuis-dev] suggestion for BoxMorph class comment

[Juan Vuletich]

Hi Mark,

On 12/19/2024 9:56 PM, Mark Volkmann via Cuis-dev wrote:
> I've been thinking a lot about the distinctions between subclassing 
> from Morph, PlacedMorph, and BoxMorph. To me it seems like the 
> following are the primary distinctions.
>
> Subclasses of `Morph`:
>
> - do not have a specified "extent" (size)
> - use the coordinate system of their owner (such as a `WorldMorph`)
>   For example, if the owner is scaled by a factor of 2 then this will 
> be also.
> - use a `VectorCanvas`
> - if the `drawOn:` method is not overridden, it will fill the morph 
> with a blue rectangle
>   that is centered at origin, has a width of 150, and a height of 140
>
> Subclasses of `PlacedMorph`
>
> - do not have a specified "extent" (size)
> - use their own local coordinate system
> - can be dragged to a new location
> - use a `VectorCanvas`
> - inherits the `drawOn:` method defined in its superclass `Morph`
>
> Subclasses of `BoxMorph`:
>
> - have an "extent" (size) specified by their `defaultExtent` method 
> which defaults to `50 at 40`
> - use a `HybridCanvas` by default, but will use a `VectorCanvas`
>   if their `requiresVectorCanvas` method returns `true`
> - if the `drawOn:` method is not overridden, it will fill the morph 
> with a light green rectangle
> - automatically clips its contents to its extent
>   (major difference between this class and the previous two!)
>
> While there is nothing wrong with the class comment for `BoxMorph`, I 
> think it would be good to emphasize that what you choose to draw 
> inside it doesn't need to be "rectangular". It seems that the 
> important thing to know is that whatever you draw will be CLIPPED to a 
> rectangle whose size is specified by what is returned from the 
> `defaultExtent` method.
>
> The warning about when we should not subclass from BoxMorph could say 
> that we should not do that unless we are okay with the clipping that 
> it provides.

Ok. Let's test this hypothesis.

First, let's play a bit with the most basic example morph included in 
the system:
evaluate: Sample01Star new openInHand.
You get a star morph. You can drop it anywhere, grab it agan, move it 
around. Open the halo. You can scale and rotate it at will. You can 
duplicate it, and embed one into the other. Now both are scaled / 
rotated together (if you grab the outer one).

Now, let's see what happens with BoxMorph, assuming it "automatically 
clips its contents to its extent".
Create StarBoxExperiment as subclass of BoxMorph. Copy 
Sample01Star>>#drawOn: here
evaluate: StarBoxExperiment new openInHand.
You get what a morph looks like when there is a problem in #drawOn. You 
also get a debugger.
Yo are right. Add #requiresVectorCanvas to answer true.
evaluate: StarBoxExperiment new openInHand.
Move the hand around.
You get a lot of drawing artifacts.

Your hypothesis is not correct. The system expects the shape of a 
subclass of BoxMorph to be a rectangle confined to (0 at 0 corner: extent), 
as described in the class comment.

Perhaps what could be added to the BoxMorph class comment is that the 
framesork system expects that behavior, and will break otherwise. And 
that the reason is to allow for simple, high performance implementation 
of SystemWindow and other simple rectangular morphs, where these 
assumptions mean that the framework doesn't need to do the extra work 
for arbitrary shapes to work correctly.

As a last comment, play with Sample07Clipping. Grab the inner star with 
the brown handle and move it around a bit. This will show the kind of 
expensive stuff that regular morphs do, but BoxMorphs avoid.

>
> -- 
> R. Mark Volkmann
> Object Computing, Inc.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241223/a4ee9813/attachment.htm>