[ENH] MorphicDependents, MasterSlaveMorph

Stephan Rudlof sr at evolgo.de
Tue May 16 02:46:36 UTC 2000


Helge,

thank you for your comments.

I know that there are many possible ways to implement such a mechanism:
I've just started with one which fills a need arising while trying to
implement a TransferMorph for drag&drop more elegantly.

I think it's good and valuable, if there is a discussion about this
topic!

A few remarks:

Helge Horch wrote:
> 
> At 07:25 15.05.2000 +0200, Stephan Rudlof wrote:
> >Change Set:             MorphicDependents
> >[...]
> >Introduces a dependency mechanism for Morphs.
> >Main goal was to have an update mechanism for dependent morphs of a
> >moved one, mainly by dragging it with the hand.
> >
> >[...]
> >Note:
> >Only BorderedMorphs are subclasses of MorphWithDependents, which has an
> >inst var for dependents; so for other morphs clean up of dependents
> >(breakDependents) has to be made manually.
> >
> >Enhancements:
> >Currently only Morph>>position:, >>color: and >>delete: send update
> >messages. Other messages could be changed similarly."
> 
> Couldn't we just use/enhance/broaden the currently present dependency
> mechanism (via MorphExtension's EventHandler)?  Every Morph can already
> have one of those.

Very important for me was not to have a speed penalty for Morphs not
'interested' in any update messages.
>From the class comment of MorphExtension:
---
MorphExtension provides access to extra instance state that is not
required in most simple morphs.  This allows simple morphs to remain
relatively lightweight while still admitting more complex structures as
necessary.  The otherProperties field takes this policy to the extreme
of allowing any number of additional named attributes, albeit at a
certain cost in speed and space.
---

My changes seem to be uncritical to me regarding speed issues, but this
has to be proved.

The mentioned TransferMorph (used in BrowserWithDragAndDrop changesets)
moves one end of a line (realized by a PolygonMorph) while dragging it.
A hint from Bob Arning has led to a first implementation by changing
>>privateFullMoveBy:, which updates aPolygonMorph stored in an inst var directly.

While cleaning up Morphic stuff (I have gotten a preliminary version)
Michael Rueger has introduced animations by using the morphic stepping
mechanism. It is possible to update dependent Morphs - like the
PolygonMorph as dependent of the TransferMorph - by some kind of
stepping, but it is 'polling'-like, whereas an update mechanism is more
'event'-like (fuzzy terminology, but I think it should be clear, what I
mean (without too much words...)).
This is OK for animations like color changes, but not, if a dependent
Morph of a grabbed one has to follow the grabbed one immediately! (at
least on my computer (Pentium 366), I have checked this).
So I have looked for a more elegant way to do this: to have a more
flexible update mechanism realized by using blocks.

The most difficult part here is the special case of the HandMorph (it
isn't just an ordinary Morph!) while dragging other Morphs.

> 
> We might extend or revise EventHandler to maintain a Dictionary with
> arbitrary event names (Symbols) as keys, and OrderedCollections of <Object,
> Message> pairs as values, or somesuch.   So we could then define new events
> on the fly.  For Messages that need a dynamic value filled in, I have used
> a BlankMessage subclass (that implements #sentTo:with: and punches the
> value into a copy of itself before sending).

EventHandler in its current form is mouse/keyboard oriented, so we could
use it e.g. for mouseMove events. But I - currently - see following
problems here:
- a speed penalty, if dispatching is too complicated;
- semantic 1: semantic has to be changed, a mouseMove event isn't the
same as a 'changed: #position';
- semantic 2: which methods should send events at all?

Possibly the speed issues are solvable or not serious, but this has to
be shown.

> 
> (Overuse of Messages?  I dunno, the class may actually be *under*used.  I
> made AspectModels from Messages/BlankMessages, and it feels a tad more
> encapsulated than distributing setSelector/getSelector/target/argument
> ivars, setters and getters to pluggable widgets.  I'll hopefully be able to
> post an example in a couple of days.)

This would be interesting!

I assume you have tried my MasterSlaveMorph class>>snakeExample: : Could
you test your suggestions with a comparable example?

Greetings,

Stephan

> 
> Just my 2c,
> Helge

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3





More information about the Squeak-dev mailing list