[Cuis-dev] An instance of Morph couldn't be moved by the halo's handle

[Szabolcs Komáromi]

Hi Juan,

Thanks for the update. This makes obvious that a Morph instance shouldn't be used inside a LayoutMorph.

My current assignment for myself is to adapt the examples of the An Introduction to Morphic: The Squeak User Interface Framework <https://rmod-files.lille.inria.fr/FreeBooks/CollectiveNBlueBook/morphic.final.pdf> paper to Cuis. I tried to translate this method:
> drawOn: aCanvas
> | colors |
> colors := color wheel: 6.
> colors withIndexDo: [:c :i |
> aCanvas fillOval: (self bounds insetBy: 4 * i) color: c].
With this:
> drawOn: aCanvas
> | colors extent |
> colors := self color wheel: 6.
> extent := self morphExtentInOwner.
> colors withIndexDo: [ :c :i |
> aCanvas strokeWidth: 0 color: Color transparent  fillColor: c do: [
> aCanvas ellipseCenter: (0 @ 0 )  radius: (extent - (4 * i))]]

But using the message morphExtentInOwner locks the image and the virtual machine uses up the available memory and I have to kill the virtual machine process. Today I realized that the morph doesn't have an extent because it is in the middle of drawing itself. :-) Even if morphExtentInOwner is nonsensical in this method maybe this qualifies as a bug. My drawOn: method is in a subclass of PlacedMorph.

Regards,
Szabolcs

On Thu, Aug 17, 2023, at 14:59, Juan Vuletich wrote:
> Hi Folks,
> 
> On 8/16/2023 5:36 PM, Szabolcs Komáromi via Cuis-dev wrote:
>> My question is more hypothetical than practical. Is it a good idea to have a kind of morph that doesn't interact uniformly with other kinds of morphs? But maybe this is an irrelevant question and I should perceive the Morph class as an abstract class.
>> 
>> Regards,
>> Szabolcs
> 
> Morph is not abstract. It can be used, although it is most useful if subclassed.
> 
> A Morph that can not be moved is a bit like (in the real world) a part that is glued or soldered to another. We see those all the time. Not all (real world) objects are equally easy to decompose into parts. I think it is a good flexibility to give to users (including developers).
> 
> WRT Morph in Layouts, yes, you found a bug. It is great to have more fresh eyes exploring the system. Some of the things that surprise you may lead to new insights on the system, but some can also be just bugs. I've just pushed an update to give an error if Morphs, that are not PlacedMorphs, are added to a Layout or a Text.
> 
> Thanks for reporting!
> 
> Cheers,
> 
>> On Wed, Aug 16, 2023, at 22:07, Hilaire Fernandes via Cuis-dev wrote:
>>> For GUI (then layout), you don't want to use Morph because it does not 
>>> have location. The idea is to remove the unnecessary attributes
>>> 
>>> Le 16/08/2023 à 20:25, Szabolcs Komáromi a écrit :
>>> > For me Morph feels a little bit broken. Too simplified and feels like 
>>> > a special case. (But I certainly doesn't have a comprehensive overview 
>>> > of Morphic in Cuis.) E.g.: If I try to add a Morph instance inside a 
>>> > LayoutMorph I get an MNU because Morph doesn't implement layoutSpec. 
>>> > It brakes the uniformity of morphs.
>>> >
>>> >> a := Morph new.
>>> >> b := LayoutMorph newColumn.
>>> >> b addMorph: a.
>>> >> b openInWorld
>>> >
>>> > But I understand what was the rationale behind it.
>>> >
>>> > Regards,
>>> > Szabolcs
>>> 
>>> -- 
>>> GNU Dr. Geo
>>> http://drgeo.eu
>>> http://blog.drgeo.eu
>>> 
>>> -- 
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>> 
>> 
> 
> 
> -- 
> 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/20230817/0c760b04/attachment.htm>