[Cuis-dev] Renaming several fundamental Morph classes

[Juan Vuletich]

Hi Bernhard,

On 12/24/2021 7:47 AM, Bernhard Pieber via Cuis-dev wrote:
> Hi Juan,
>
> Here are my two cents:
>
> I first encountered the term widget in the Motif X Windows UI framework. I remember this well because I had to look it up at the time. I learned that in the real world a widget is a component of a window. So the metaphor made sense: Windows and Widgets.
>
> In Morphic we use the terms Windows and Morphs instead:
>
> | suffixes |
> suffixes := (Morph allSubclasses collect: [:each | each name
> 	copyFrom: (each name findLast: [:char | char isUppercase])
> 	to: each name size]) asBag.
> suffixes sortedCounts.
>
> "Base a SortedCollection(47 ->  'Morph' 27 ->  'Window' 1 ->  'Item' 1 ->  'Many' 1 ->  'Bar' 1 ->  'Pane')"
> "CorePackages: a SortedCollection(48 ->  'Morph' 30 ->  'Window' 1 ->  'Many' 1 ->  'Pane' 1 ->  'Bar' 1 ->  'Sonogram' 1 ->  'Item')"
>
> So I would avoid using the term widget at all in Cuis as part of class or method names. It could be used in package or class category names as widget library seems to be the most frequently used term for libraries of UI components. The same reasoning applies to the term control, which is used in Windows UI frameworks instead of widget.
>
> To sum up, in my opinion all Morph subclasses should either end with Morph or Window.

I essentially followed this suggestion in the last proposal I just 
emailed. Thanks.

> As others have suggested I would rename MorphicWidget to RectangularMorph. The existing class comment fits it perfectly then.

See the other email I just sent.

> Regarding MovableMorph: I see that even with all packages loaded MovableMorph is the only subclass of Morph. So one possibility would be to merge it into Morph. What would be a good example of a sibling class to MovableMorph?

I haven't implemented any yet, but I was thinking, for example, on a 
morph that is a function, in a FunctionGraphMorph. The graph sets the 
space (the coordinate system) for the functions it shows. Each function 
can't and shouldn't be moved. If you move the sin(x) function 1 upwards, 
it becomes sin(x)+1, and that's a different function. So it is for 
morphs that can't be moved at all.

> If you don’t want to merge it: It has two instance variables: location and layoutSpec, so other names might be PositionableMorph or LayoutableMorph.

I propose LocatedMorph, after some recent suggestion in this thread.

> Regarding KernelMorph: I would merge it with RectangularMorph. It shares the instance variables extent and color. Then a PasteUpMorph could have a border.
>
> Speaking of PasteUpMorph: I don’t mind the name. PlaygroundMorph would fit the class comment. For me it is an area to freely lay out and move around other morphs, so what about LayoutBoardMorph or shorter BoardMorph?
>
> Regarding WorldMorph: I don’t mind the name. A slightly more understandable name to newcomers might be DesktopMorph.
>
> Cheers,
> Bernhard
>

See the other email with my current proposal. Let's follow up discussion 
there.

Thanks!

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
@JuanVuletich