[Cuis-dev] PlacedMorph vs BoxedMorph

[Juan Vuletich]

Hi Hilaire,

(inline)
On 8/31/2024 10:56 AM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi,
>
> Looking at these two classes, it seems BoxedMorph has too much 
> responsibilities and PlacedMorph not enough.
>
> Indeed, PlacedMorph has BoxedMorph as its only heir. Moreover, there 
> is no instance of PlacedMorph.
>

Not quite:
PlacedMorph subclasses ->
#(BoxedMorph Sample01Star Sample02Bezier Sample03Smiley Sample04Pacman 
Sample06EasyToGrab Sample07Clipping Sample08Form Sample09Clock 
Sample09ClockHourHand Sample09ClockMinuteHand Sample09ClockSecondHand 
Sample10PythagorasTree) .

PlacedMorphs are not expected to be "boxes". That's the big difference. 
They are also not assumed to be resizable. That's why having an instance 
variable to hold something like 'extent' is not appropriate for them.

> *I am wondering if moving the extent attribute of BoxedMorph to 
> PlacedMorph *would be useful.
>

I don't think so. It is important to have a superclass for Morphs that 
are not rectangular shapes, or have their own idea of how to handle 
their size / extent.

> I have many situation where I am interested by a morph with extent and 
> location but without interest to color, border, and friends. But I 
> find myself in the situation I have to subclass BoxedMorph ending with 
> a class with the unnecessary attributes color, border, etc.
>
> PlacedMorph is the minimum the user can add to a layout morph, because 
> of that PlacedMorph have method with extent consideration. So it is a 
> bit odd.
>

PlacedMorphs are expected to be movable around. That's why you can add 
them to a layout. See the most basic example of non-rectangular morph 
with constant size: Sample01Star . Clearly, a Sample01Star has a well 
defined extent. But it can't change. And it doesn't even need to specify 
it: it is a consequence of how it is drawn. I think this possibility is 
pretty unique to Cuis' Morphic 3 framework.

> Hilaire
>
> -- 
> GNU Dr. Geo
> http://gnu.org/s/dr-geo/
> http://gnu-drgeo.blogspot.com/

I understand your need. I think a better hierachy would be something like:
Morph
     PlacedMorph (location)
         BoxedMorph (extent)
             ColoredBoxedMorph (color, borderWidth, borderColor)
                 Many subclasses here

The problem with this approach is that a lot of code is already 
subclassing BoxedMorph. It may be more reasonable to add a new class 
between PlacedMorph and BoxedMorph. Something like:
Morph
     PlacedMorph (location)
         BasicBoxedMorph (extent)
             BoxedMorph (color, borderWidth, borderColor)

Thoughts?

-- 
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/20240901/da626be5/attachment-0001.htm>