<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> On 12/21/2021 4:02 PM, Juan Vuletich via Cuis-dev wrote: <blockquote cite="mid:61C224D2.8030606@zoho.com" type="cite">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, </blockquote> 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: <blockquote type="cite">My poor Juan, I think we add a lot of confusion we our opinions ;-)</blockquote> 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 <blockquote type="cite">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 </blockquote> <blockquote type="cite">I like the other names, but perhaps MovableMorph -> LocatedMorph</blockquote> <blockquote type="cite"> <pre wrap="">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.</pre> </blockquote> 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: <blockquote type="cite">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? </blockquote> <blockquote type="cite">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).</blockquote> <blockquote type="cite"> 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.</blockquote> <blockquote type="cite">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.</blockquote> 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 <blockquote type="cite">So GUIControlMorph will be rectangular widget, this is what is expect in graphical control element. Make sense </blockquote> <blockquote type="cite">. 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. </blockquote> <blockquote type="cite">And about WidgetMorph I’d keep that name and make it subclass of RectangularMorph (it just adds borderWidth and borderColor).</blockquote> <blockquote type="cite">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.</blockquote> <blockquote type="cite"> <pre wrap="">As others have suggested I would rename MorphicWidget to RectangularMorph. The existing class comment fits it perfectly then. </pre> </blockquote> 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 <blockquote type="cite">The proposed names are more meaningful for me. </blockquote> <blockquote type="cite">. 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.</blockquote> <blockquote type="cite">Actually, I think PasteUpMorph is a better name to keep. (+1) </blockquote> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <blockquote type="cite"> <pre wrap="">Regarding WorldMorph: I don’t mind the name. A slightly more understandable name to newcomers might be DesktopMorph. </pre> </blockquote> 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: <blockquote type="cite">I am wondering, do we need to drag these Morph post/prefix?</blockquote> <blockquote type="cite">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) </blockquote> <blockquote type="cite">. I would keep for sure the "morph" part at the end for all names (as already suggested) </blockquote> <blockquote type="cite">Also I think we should call all morphs *Morph, at least in the base image.</blockquote> <blockquote type="cite"> <pre wrap="">To sum up, in my opinion all Morph subclasses should either end with Morph or Window.</pre> </blockquote> Ok. Let's keep the status quo with these, forget about the 'widget' word. At least for now. More general or "global" comments: <blockquote type="cite"> 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.</blockquote> Thanks. That is a good take, but see below, after considering other ideas and opinions. <blockquote type="cite">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.</blockquote> 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, <pre class="moz-signature" cols="72">-- Juan Vuletich <a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a> <a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a> <a class="moz-txt-link-freetext" href="https://www.researchgate.net/profile/Juan-Vuletich">https://www.researchgate.net/profile/Juan-Vuletich</a> <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a> <a class="moz-txt-link-freetext" href="https://independent.academia.edu/JuanVuletich">https://independent.academia.edu/JuanVuletich</a> @JuanVuletich</pre> </body> </html>