[Cuis-dev] How to represent Morphs with multiple parents in Morphic?

Ian Jeffries mail at ianjeffries.net
Thu Mar 28 10:06:26 PDT 2024


Thank you for your response. All of it was interesting, but I'm just going
to write up my thoughts on this part since I'm guessing it's the crux of
the matter:

> Morphs, along with their code, are the visible representation and have
strict _visual_ containment.

I've been looking at Morphs as the intersection point where the user's
direct manipulation[1] abilities connect with the data model of the
application. In the case of Morphs that means I've been trying to program
such that the Morphic halo actions like "Duplicate", "Move", etc are as
useful to the user as I can make them.[2]

And it's this intersection point of the user's actions and the app's data
model that I'm trying to understand better. In particular, I agree that the
parent/child submorph relationship doesn't work for what I'm trying to do
here. It's the tradeoffs of the other options I'm trying to feel out.

Let's go back to the example, but tweak it some since a Highway segment can
exist even if one of the cities it connects is removed.

Consider a Simulation app with Cities and RadioLinks between them. The
latter are represented visually as a dashed line and should never exist
without a City at both ends. Our goal is for each halo action to be as
useful as possible. Consider "Remove": we'd like "Remove" on a City to not
just delete the city visually, but also (a) delete it from the simulation's
data model, and (b) delete any RadioLink that has the city as one of its
ends.

Some ways I can think of to do this:

1. Make RadioLink not a Morph, but rather implicit to the program. Use the
Simulation's `drawOn` method to draw them and put their logic (for moving
simulation packets around or whatever) inside of Simulation or City. This
has the downside that users can no longer access them through the halo menu
for changing their color or viewing their code. However it has the upside
that it makes "Remove" on City behave the way users will expect: it will
now also remove radio links.

2. Make RadioLink a Morph. Add custom code to `delete` for City that
removes incident RadioLinks.

3. Make RadioLink a Morph. Generalize the solution in (2) to add a custom
`dependsOn` message to Morphs so that when a Morph is removed from the
Simulation, the Simulation removes any morphs that depended on it in a
cascade.

Though as I type this up I realize that the particular details of this
problem aren't so important to me (though I'd certainly appreciate
suggestions on what people would do).

Rather this is an example of a whole class of problems I haven't
encountered before: how to program in a way that makes the best use of
powerful, builtin user actions like Morphic halos. Any reading
recommendations along those lines would be very appreciated.

[1] In the Design Principles Behind Smalltalk
<https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html> sense.

On Tue, Mar 26, 2024 at 4:03 PM <ken.dickey at whidbey.com> wrote:

> On 2024-03-26 12:31, Ian Jeffries via Cuis-dev wrote:
>
> > For instance this might be an edge in a graph which connects two nodes.
> > Or to use a more specific example this might be a segment of Highway or
> > River between two Cities.
>
> Morphs, along with their code, are the visible representation and have
> strict _visual_ containment.
>
> This is unrelated ("orthogonal") to other relations like connections
> between nodes.
>
> > I'd like to say that the Highway has two parents, so if either City is
> > removed then the Highway is removed as well. However the Morph/submorph
> > relationship is strictly hierarchical so this isn't possible.
>
> You can have a glass in a bottle in a bucket, but you can't have the
> glass in two separate buckets.  ?Remove either bucket and the glass is
> removed as well?
>
> The metaphor does not work in this case.
>
> > This makes me think the right thing to do is to place the edges at the
> > same level in the Morph hierarchy as the nodes. Thus a Highway and both
> > the Cities it connects would all be same-level submorphs of their
> > parent. I can override the `delete` message of City to remove any
> > adjacent Highways that start or end there.
>
> Both cities may be in a country.  If you delete (nuke?) one city you
> might update the node/highway relationships.  A city may span a border.
> Does either country strictly "contain" the city?
>
> > However, that would mean City needs to know about each object that
> > might be an implicit submorph of it in this way. Another strategy would
> > give morphs some kind of `implicitParents` field (not a real name
> > suggestion), and when a morph is deleted it checks for any adjacent
> > morphs that list it as an `implicitParent` and deletes those as well.
> >
> > Does it seem like I'm on the right track, and does anyone have
> > suggestions for the best way to handle this?
>
> One way to think of this is like "creation relations".  You want to
> maintain relationships, which may themselves be represented as objects.
>
> E.g. one creates an automobile, but each gets its own tires, engine,
> windshield.  Deleting a GM factory does not delete the cars or their
> engines.  Deleting a road does not delete the cars.
>
> So my suggestion would be to use consistent object metaphors.
>
> I would hope you might have time to look at tutorials and examples in
> https://github.com/Cuis-Smalltalk/Learning-Cuis
>
> HTH,
> -KenD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240328/82869dbb/attachment.htm>


More information about the Cuis-dev mailing list