Stefan Matthias Aust wrote:
> 
> At 07:25 15.05.00 +0200, Stephan Rudlof wrote:
> >Dear Squeakers,
> >
> >following changesets introduce a dependents mechanism and a morph which
> >uses it for Morphic.
> 
> Stephan, did you considered to use the newer event system instead of the
> older update/changed system.

I have made some comments about this in this thread before (see below).
I'm not an expert of the newer event system, so some remarks may be
insufficient.

> The latter always broadcasts changes and
> therefore isn't as fast as the newer system

If there are no dependents, there isn't any broadcasting. Currently only
for special morphs - like e.g. the MasterSlaveMorph - there are
dependents.

> which also doesn't require you
> to always change the #update: method.

The #update:from: method only has to be changed for morphs, which want
to react to updates (e.g. the MasterSlaveMorph), not for other morphs.

> 
> Furthermore, the way Morphs already support some events, see #on:send:to:
> which I think could be generalized and also based on the current event
> system.

Surely.

>  Eventually, all that simple "self changed" should be then replaced
> with "self trigger: #positionChanged" or similar events.

That's interesting! I haven't noticed #trigger: messages before...

I've just started with an approach familiar to me to
- solve a *concrete* problem (please try the example),
- start a discussion - like this one -,
	- open for suggestions for better implementations (good),
	- open for *changesets* of better implementations (better).

Is there anyone who wants to post an improved implementation?
It should be
- tested with the same example (regarding functionality) as given by
MasterSlaveMorph class>>snakeExample:,
- with comparable or better speed.

> 
> bye

My previous mail in this thread:

Stephan Rudlof wrote:
> 
> 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

Greetings,

Stephan
-- 
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