<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Mark,<br>
<br>
On 12/19/2024 9:56 PM, Mark Volkmann via Cuis-dev wrote:
<blockquote
cite="mid:CAFfRWnUoGYi8iE2k-yGWkuebzpfXJqmXNkTGVsXXT8-RuP9LRw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div>Subclasses of `Morph`:<br>
<br>
- do not have a specified "extent" (size)<br>
- use the coordinate system of their owner (such as a
`WorldMorph`)<br>
For example, if the owner is scaled by a factor of 2 then
this will be also.<br>
- use a `VectorCanvas`<br>
- if the `drawOn:` method is not overridden, it will fill the
morph with a blue rectangle<br>
that is centered at origin, has a width of 150, and a height
of 140<br>
<br>
Subclasses of `PlacedMorph`<br>
<br>
- do not have a specified "extent" (size)<br>
- use their own local coordinate system<br>
- can be dragged to a new location<br>
- use a `VectorCanvas`<br>
- inherits the `drawOn:` method defined in its superclass
`Morph`<br>
<br>
Subclasses of `BoxMorph`:<br>
<br>
- have an "extent" (size) specified by their `defaultExtent`
method which defaults to `50@40`<br>
- use a `HybridCanvas` by default, but will use a
`VectorCanvas`</div>
<div> if their `requiresVectorCanvas` method returns `true`<br>
- if the `drawOn:` method is not overridden, it will fill the
morph with a light green rectangle<br>
- automatically clips its contents to its extent<br>
(major difference between this class and the previous two!)<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
Ok. Let's test this hypothesis.<br>
<br>
First, let's play a bit with the most basic example morph included
in the system:<br>
evaluate: Sample01Star new openInHand.<br>
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).<br>
<br>
Now, let's see what happens with BoxMorph, assuming it
"automatically clips its contents to its extent".<br>
Create StarBoxExperiment as subclass of BoxMorph. Copy
Sample01Star>>#drawOn: here<br>
evaluate: StarBoxExperiment new openInHand.<br>
You get what a morph looks like when there is a problem in #drawOn.
You also get a debugger.<br>
Yo are right. Add #requiresVectorCanvas to answer true.<br>
evaluate: StarBoxExperiment new openInHand.<br>
Move the hand around.<br>
You get a lot of drawing artifacts.<br>
<br>
Your hypothesis is not correct. The system expects the shape of a
subclass of BoxMorph to be a rectangle confined to (0@0 corner:
extent), as described in the class comment.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAFfRWnUoGYi8iE2k-yGWkuebzpfXJqmXNkTGVsXXT8-RuP9LRw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div><font face="arial, helvetica, sans-serif">R.
Mark Volkmann</font></div>
<div><span style="font-size: 12.8px;"><font
face="arial, helvetica, sans-serif">Object
Computing, Inc.</font></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Cheers,<br>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>