[Cuis-dev] [RFC][Proposal] A possible refactor of the Morph hierarchy

[Juan Vuletich]

Hi Folks,

I was trying to think on how to present Morphic to a newcomer for 
https://github.com/Cuis-Smalltalk/TheCuisBook .

Morphic is based on ideas that are pretty different from those of most 
UI frameworks. The Morphic implementation in Cuis, even more so. But 
still, it includes a set of Widgets (PluggableMorph, LayoutMorph, 
MenuMorph, etc) that can be used to build rather conventional GUIs, like 
the Browser and other programming tools. All this deserves to be 
described clearly in TheCuisBook, that Hilaire, Ken and I are writing.

RectangleLikeMorph and BorderedRectMorph are the root of subhierarchies 
that include all the widget-like morphs. But, yet again, I thought that 
those names suck. They are too bad to talk seriously about them in a 
book. So, this proposal, that I have already been playing with during 
the weekend:

- Add a new subclass of Morph, called WidgetMorph that essentially 
includes all of RectangleLikeMorph and BorderedRectMorph.
- Make all subclasses of BorderedRectMorph (except for EllipseMorph and 
PasteUpMorph) to be subclasses of WidgetMorph
- Make all subclasses of RectangleLikeMorph (except for 
BorderedRectMorph, HaloMorph, HaloHandleMorph and HandMorph) be 
subclasses of WidgetMorph, with a defaultBorderWidth of zero

In this way, all Widget morphs will be in the WidgetMorph hierarchy, 
improving consistency and making it easier to explain and remember.

- RectangleLikeMorph and BorderedRectMorph might get deleted. 
PasteUpMorph, HandMorph, HaloMorph, HaloHandleMorph and EllipseMorph 
could be subclasses of Morph. This will need some rework of their internals.

- Additionally, I want to rename StringMorph as LabelMorph, as 'label' 
is less ambiguous, and is how a read-only string widget is usually called.

The only things that I think could impact back compatibility are the 
removal of RectangleLikeMorph and BorderedRectMorph (that might be 
subclassed in external packages), and StringMorph that is probably used 
in many places. I think a reasonable alternative is to include them in a 
new package, that we might call DeprecatedMorphs.pck.st or 
BackCompatibilityMorph.pck.st .

Thoughts? Suggestions for improving this sketch?

Thanks,

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