[Cuis-dev] Renaming several fundamental Morph classes

[Juan Vuletich]

On 12/21/2021 4:02 PM, Juan Vuletich via Cuis-dev wrote:
> Hi Folks,
>
> It has become apparent that some class names I chose some time ago are 
> not meaningful enough. The most confusing is the meaning I assumed for 
> "Widget". Decades ago, Widget meant "UI element in some library". 
> Today it means "Anything the user can interact with". So, I want to do 
> the following renames:
>
> MovableMorph    -> MorphicWidget
> WidgetMorph      -> GUIControlMorph
> KernelMorph       -> SpecialMorph
> WorldMorph        -> MorphicWorld
> PasteUpMorph   -> PlaygroundMorph
>
> I hope these convey meaning more effectively.
>
> There will be impact on some packages. I have changesets ready to be 
> applied for all packages in repos in the Cuis-Smalltalk organization.
>
> Before applying all this:
> Do you like the new names? Do you know better ones to suggest?
> Any other thoughts?
>
> Thanks,

Hi Folks,

Thanks for the feedback! This is very helpful and encouraging. It will 
help shape Morphic to be more meaningful and easier to understand and use!

There are many thoughts and opinions in this thread. All of them are 
valuable and insightful. I'll try to briefly review them now. I didn't 
include the author of each opinion. In any case, opinions stand for 
themselves:

> My poor Juan, I think we add a lot of confusion we our opinions ;-)

Thanks for the sympathy! I think this is a great community exercise, and 
I find it fun. Let's see how it goes!

1) WRT MovableMorph / MorphicWidget

> It makes sense, because a widget is a graphic element the user can 
> interact with. Whatever its shape, rectangular or not.
> Will naming the class only Widget makes sense 

> I like the other names, but perhaps
>  MovableMorph -> LocatedMorph

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

Given various comments about the meaning of the word "widget" and its 
evolution over time, maybe LocatedMorph is the best option.

2) WRT KernelMorph / SpecialMorph:

> Kernel was not great, because you can wonder why it is kernel, why 
> Morph is not the kernel.
> Can you explain what is special with SpecialMorph? 

> I've been thinking about it and I would rename KernelMorph to 
> RectangularMorph, as in the original Morphic, because I think having 
> rectangular bounds is enough to call it "rectangular". It's not a 
> rectangle, tho (it wouldn't make sense to call it RectangleMorph).

> Yes. The RectangularMorph or maybe just RectMorph will be more 
> meaningful than Kernel/SpecialMorph. Some user will read Rectangle and 
> be confused, because subclass of KernelMorph can be non rectangle 
> (Think about a disc or an ellipse)
>
> In that case I will call it a BoxyMorph or BoxMorph because a 
> rectangular, ellipse, or any other shape defined by its -x and -y 
> extents are kind of box.

> And I don't think we should make the hand and the world "special" by 
> giving them a special superclass. I think trying to separate "system" 
> morphs from "user" morphs is not a good idea, all morphs should be 
> regarded on the same conceptual level, all are morphs and there's 
> nothing special about them except implementation details.

My idea of separating these "special" hierarchy was not a good one. I 
agree that this should be merged with current WidgetMorph hierarchy, 
under better names. KernelMorph could simple be called RectMorph.


3) WRT WidgetMorph / GUIControlMorph

> So GUIControlMorph will be rectangular widget, this is what is expect 
> in graphical control element.
> Make sense 

> . WidgetMorph wasn't it just a rectangle ? So why not RectangularMorph 
> ? Or maybe BasicMorph
> or SimpleMorph. "GUIControlMorph" sounds to me something with sliders 
> and buttons. 

> And about WidgetMorph I'd keep that name and make it subclass of 
> RectangularMorph (it just adds borderWidth and borderColor).

> No. Because the intend of Juan is to make Widget not limited to 
> Rectangular like widget, but to extend it to widget with any kind of 
> shape. So it can't be a sublcass of KernelMorph. In Juan, renaming 
> scheme, this is GUIControlMorph which could be a subclass of KernelMorph.

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

Given that we are also removing the "Kernel" or "Special" distiction, I 
think WidgetMorph could be renamed as BorderedRectMorph, and made 
subclass of RectMorph (today called KernelMorph).


4) WRT WorldMorph / MorphicWorld and PasteUpMorph / PlaygroundMorph

> The proposed names are more meaningful for me. 

> . I have a strong dislike for "playgroundXXX" . I don't like it in 
> Pharo Workspace, i don't like it in Apple products.
> I think the word "play" should be reserved to children or recreative 
> activity.

> Actually, I think PasteUpMorph is a better name to keep. (+1)

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

I think that for now, it makes sense to keep these names as they are 
today. Maybe rediscuss them after this round of changes.


5) WRT the 'Morph' or 'Widget' prefix:

> I am wondering, do we need to drag these Morph post/prefix?

> I'm not sure about MorphicWidget and MorphicWorld, it seems more 
> consistent to name subclasses of Morph with the 'Morph' suffix. Unless 
> your intention is to start naming subclasses of MorphicWidget with 
> 'Widget' suffix, and in that case Widget might be a nicer name than 
> MorphicWidget. Just some thoughts. (+1)

> . I would keep for sure the "morph" part at the end for all names (as 
> already suggested) 

> Also I think we should call all morphs *Morph, at least in the base image.

> To sum up, in my opinion all Morph subclasses should either end with Morph or Window.

Ok. Let's keep the status quo with these, forget about the 'widget' 
word. At least for now.

More general or "global" comments:

> Reading at your email, we want coherent names for these fundamental 
> classes. Here is a distilled proposal from your suggestions:
>
> MovableMorph  -> MorphicWidget   -> *WidgetMorph *(subclass of Morph)
> WidgetMorph      -> GUIControlMorph -> *RectWidgetMorph *(subclass of 
> WidgetMorph as for now)
> KernelMorph       -> SpecialMorph -> *BoxyMorph */*BoxMorph *(subclass 
> of WidgetMorph)
> WorldMorph + PasteUpMorph   -> *WorldMorph*
>
> I think having both WidgetMorph and RectWidgetMorph names (or anything 
> with the same idea) will help the future users to distinguish these 
> two kinds of widget and not be confused as I was.
>
> As Luciano mentioned it, we can wonder why in the current name scheme 
> WidgetMoprh is not a subclass of KernelMorph. But maybe we can keep 
> this for later and Juan may have some good reason.

Thanks. That is a good take, but see below, after considering other 
ideas and opinions.

> What's the difference between the current KernelMorph and WidgetMorph? 
> They have duplicated code, and the only difference seems to be that 
> WidgetMorph has border. So they are kind of the old RectangularMorph 
> and BorderedMorph, if I remember correctly. If KernelMorph is only 
> there to separate "system" morphs from "user" morphs I think it 
> shouldn't exist.

Ok. Ok. My idea was to suggest people to put aside a bit those "kernel" 
or "special" morphs, because they have a lot of complexity to support 
Morphic itself; but new, additional morphs usually don't need this kid 
of details. Anyway, lets remove that distiction.

This is my current suggestion, that tries to follow consensus:

Morph
     LocatedMorph (location) [today's MovableMorph]
         RectMorph (extent, color) [to replace KernelMorph and part of 
WidgetMorph]
             BorderedRectMorph (borderWidth, borderColor) [rest of 
today's WidgetMorph]
             PasteUpMorph [no change]
                 WorlddMorph [no change]
             PluggableMorph [no change]

Please keep the discussion going!

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211226/dc605f30/attachment.htm>