[squeak-dev] Morphic

Hannes Hirzel hannes.hirzel at gmail.com
Wed Sep 22 06:21:11 UTC 2010


Thank you Sean, for bringing up this topic,

joining a bit late, here a few remarks.

--Hannes

On 9/17/10, DeNigris Sean <sean at clipperadams.com> wrote:
> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.
> Many people seem to really not like it and complain about it, but it seems
> very vague i.e. they can't point to a specific problem with it.
>
> I think it's amazingly powerful and universally misunderstood.  Many people
> are pushing for native widgets for end users, which I think is awesome, but
> serves a different role.  For me, there are two use cases:
> 1. People (mostly Smalltalkers, including myself) interested in the UI's of
> the future and exploring what's possible

Yes,

> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g.
> enterprise) where they have to use a particular GUI.

> Morphic seems ideal for group #1.  I think the key questions are:
> * if you were implementing Morphic today, knowing what you know after it
> being used over the years, how would you do it?
> * what would it take (if possible) to get there from the current
> implementation?
>
> Two issues I've noticed:
> 1. there seems to be an explosion of classes with slightly different
> behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph,
> PluggableShoutMorph.
> 2. I'm not clear whether the hooks for modifying behavior are
> 	a. available in all the right places
> 	b. working
> 	c. widely understood

Yes

> I'm forming an informal panel to discuss this.  I've reached out to
> Morphic's creators and some original users.
>
> A quick example of my (seemingly common) experience:
> For example, I'm writing an implementorsOf browser that shows the execution
> path as a graph of MethodMorphs connected by LineMorphs, because the
> standard paned browser does not capture the metaphor of drilling down
> through implementors.  So I Created a MethodMorph and added as a submorph a
> PluggableShoutMorph to hold the code.  At that point, I couldn't figure out
> a good/easy way to react to mouse events and pop out a new MethodMorph.
>
> I tried (one of these felt very satisfying):
> * Morph>>on:send:to:, which sounded good, but never got called
> * intercepting Morph>>processEvent:using: (which I was told was not a good
> idea)
> * (after seeking help), locking the submorphs and overriding the dozen or so
> event-related methods in the chain from my morph to TextMorphForShout (the
> Morph that actually handles the text and input).
> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to
> use that subclass.

Which method did you like best?

There are some notes on this issue at
http://wiki.squeak.org/squeak/2477
( Eddie Cottongim writes: I know of three main ways to handle events
in Morphic.......)

I assume Juan does not have this variety anymore in his CUIS image.....


Conclusion: It might be worthwile to find out more how Juan has pruned
Morphic in Cuis and if it is still valuable for use, document that and
put it to use in Squeak and Pharo.

I have started reading the Cuis code, it is helpful for understanding
Morphic and once you know your way around you do not mind so much that
there are a lot of other things.



More information about the Squeak-dev mailing list