[Cuis-dev] suggestion for BoxMorph class comment

[Mark Volkmann]

Thanks so much for taking the time to reply! See my feedback inline below.

On Mon, Dec 23, 2024 at 12:47 PM Juan Vuletich <juan at cuis.st> wrote:

> 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).
>

This all makes sense to me because Sample01Star is a subclass of
PlacedMorph, not just Morph.

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.
>

I see the artifacts. After selecting "Restore Display" from the World menu,
I also see that the star seems to be clipped to the rectangle defined by
the extent. I think I confirmed that by adding the following to the drawOn:
method.

aCanvas strokeWidth: 2 color: Color red do: [
    aCanvas
        moveTo: 0 @ 0;
        lineTo: extent x @ 0;
        lineTo: extent x @ extent y;
        lineTo: 0 @ extent y;
        lineTo: 0 @ 0
].

That renders the attached screenshot.

 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.

Is it wrong to say that a BoxMorph clips its contents to the rectangle
defined by 0 at 0 and its extent? It seems to do that regardless of what is
drawn on the BoxMorph. I think the point you are making is that it is *bad*
to draw outside of a BoxMorph (and violates a restriction stated in the
class comment) due to the artifacts that appear if the morph is dragged. I
understand that now. Thanks for explaining that!

Perhaps what could be added to the BoxMorph class comment is that the
> framework system expects that behavior, and will break otherwise.
>

Where "break" means it will result in drawing artifacts only if the morph
is dragged?


> 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.
>

Got it.


> 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.
>

Nice!

-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241223/77fdcf70/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2024-12-23 at 6.57.16?PM.png
Type: image/png
Size: 1422 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241223/77fdcf70/attachment.png>