<div dir="ltr"><div dir="ltr">Juan,<div><br></div><div>Not wild about the StringMorph->LabelMorph idea... looks like rearranging the lawn furniture to me as the existing name seems accurate and clear.  Re: the rest, hopefully the final step would be to merge RectangleLikeMorph and BorderedRect back into RectangleMorph and move it to someplace like goodies.  The first question new users often have re: Morphic is 'how do I instantiate or create my own Morph?' and a clean RectangleMorph would provide that as a trivial Morph for instantiating and subclassing. (i.e. rather than deprecating it and prolonging the confusion/pain, keep a cleaned up version around specifically for tutorials/testing where you don't have to worry about features creeping in over the years breaking things)  Also, make sure the widget class is explicitly documented as abstract just like Morph should be (how many times have we had people confused about why instantiating Morph has problems?)<br></div></div><div><br></div>Thanks,<div>Phil</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 10:43 AM Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Folks,<br>
<br>
I was trying to think on how to present Morphic to a newcomer for <br>
<a href="https://github.com/Cuis-Smalltalk/TheCuisBook" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/TheCuisBook</a> .<br>
<br>
Morphic is based on ideas that are pretty different from those of most <br>
UI frameworks. The Morphic implementation in Cuis, even more so. But <br>
still, it includes a set of Widgets (PluggableMorph, LayoutMorph, <br>
MenuMorph, etc) that can be used to build rather conventional GUIs, like <br>
the Browser and other programming tools. All this deserves to be <br>
described clearly in TheCuisBook, that Hilaire, Ken and I are writing.<br>
<br>
RectangleLikeMorph and BorderedRectMorph are the root of subhierarchies <br>
that include all the widget-like morphs. But, yet again, I thought that <br>
those names suck. They are too bad to talk seriously about them in a <br>
book. So, this proposal, that I have already been playing with during <br>
the weekend:<br>
<br>
- Add a new subclass of Morph, called WidgetMorph that essentially <br>
includes all of RectangleLikeMorph and BorderedRectMorph.<br>
- Make all subclasses of BorderedRectMorph (except for EllipseMorph and <br>
PasteUpMorph) to be subclasses of WidgetMorph<br>
- Make all subclasses of RectangleLikeMorph (except for <br>
BorderedRectMorph, HaloMorph, HaloHandleMorph and HandMorph) be <br>
subclasses of WidgetMorph, with a defaultBorderWidth of zero<br>
<br>
In this way, all Widget morphs will be in the WidgetMorph hierarchy, <br>
improving consistency and making it easier to explain and remember.<br>
<br>
- RectangleLikeMorph and BorderedRectMorph might get deleted. <br>
PasteUpMorph, HandMorph, HaloMorph, HaloHandleMorph and EllipseMorph <br>
could be subclasses of Morph. This will need some rework of their internals.<br>
<br>
- Additionally, I want to rename StringMorph as LabelMorph, as 'label' <br>
is less ambiguous, and is how a read-only string widget is usually called.<br>
<br>
The only things that I think could impact back compatibility are the <br>
removal of RectangleLikeMorph and BorderedRectMorph (that might be <br>
subclassed in external packages), and StringMorph that is probably used <br>
in many places. I think a reasonable alternative is to include them in a <br>
new package, that we might call <a href="http://DeprecatedMorphs.pck.st" rel="noreferrer" target="_blank">DeprecatedMorphs.pck.st</a> or <br>
<a href="http://BackCompatibilityMorph.pck.st" rel="noreferrer" target="_blank">BackCompatibilityMorph.pck.st</a> .<br>
<br>
Thoughts? Suggestions for improving this sketch?<br>
<br>
Thanks,<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis-smalltalk.org" rel="noreferrer" target="_blank">www.cuis-smalltalk.org</a><br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a><br>
<a href="https://github.com/jvuletich" rel="noreferrer" target="_blank">https://github.com/jvuletich</a><br>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" rel="noreferrer" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a><br>
@JuanVuletich<br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div></div>