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

[Phil B]

Juan,

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

Thanks,
Phil

On Tue, Oct 13, 2020 at 10:43 AM Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201013/af1b9757/attachment-0001.htm>