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

Luciano Notarfrancesco luchiano at gmail.com
Tue Oct 13 11:22:44 PDT 2020


Great, I like the idea of WidgetMorph, and getting rid of those two classes
with weird names... ;)

On Tue, 13 Oct 2020 at 9:43 PM, 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/20201014/97a0fc56/attachment.htm>


More information about the Cuis-dev mailing list