Stefan Matthias Aust wrote:

> The HandMorph is ugly. 230 methods. It's frightenend.  It needs a redesign.
> But as it's so large, I don't dare to do it alone.  So because nobody
> dared to touch this class, I have to send out this long email.  It tries to
> identify what the HandMorph's methods do and makes somes suggestions what
> could be changed.

Stefan,

I think the HandMorph is high on everyone's list of "room for improvement"
in Morphic. However, backward compatibility would become very "interesting"
I'm afraid.

(hint! hint!) Also, I think a lot of us are holding back our desires until
we know what is in store for the Morphic update scheduled for this fall.

> First of all, I'm one of these "separate model, view, and application
> logic" guys.  So I'm in favor for removing everything that looks like model
> or application logic from that class.

It seems you are referring to some kind of "3-tier" model that is in vogue
in the 1000-page-programming-book category these days. However, Morphic is
not just another version of MVC. The whole point of Morphic is to replace
MVC since it's too low-level and complicated. In comparison, would you want
to put the printing methods, or the 'accessing' methods, of every class in
their own auxiliary class? This is where all the aspects/perspectives stuff
comes in; I'm not really interested in debating MVC vs. MVx, I just think
that it is important to understand Morphic on its own terms; its "theory" as
it has come to be known.

A big conceptual problem is that Morphic still needs to support all the
widgets that are very MVC in their style, and this is not how it should be
used ideally. But it's what happens when you graft a new idea, however good,
into an old context: The great concepts gets well concealed behind all the
duct tape needed to patch it together with all the old stuff. A second
important point is that Squeak lacks the prototype capabilities of Self;
this takes it even further from the perspectives style that would be needed
for an ideal implementation.

>> The following stuff doesn't belong to the HandMorph IMHO.  The world morph
>> menu should be implemented by the WorldMorph (aka PasteUpMorph) itself and
>> most methods can be best moved to a nice singleton instance that represents
>> the global functions of the Smalltalk system.  It might be also nice if
>> tools can be registered using that singleton instead of being hard coded
>> into the this morph.

John M agreed that the Hand menu methods could be factored out, so you could
go ahead and do this; just coordinate yourself with him before you go ahead
since he is working on this general topic as well. It would be a good idea
to factor out the corresponding menu stuff from Morph itself at the same
time.

As John pointed out, Disney gives SqC time to crank out new stuff, but not
for going back and getting it right when they know how they should have done
it! Morphic is IMHO the best evidence of this: the successive layers of
evolutionary development are rather evident: there have been added scaling
and rotation; two generations of scripting; Balloon; etc...

However, fixing the Hand should involve changing the logic, not merely
moving the methods around. Most importantly, this concerns the way Morphic
distributes responsibility for handling events (not a big surprise perhaps;
I guess that is what a Hand should do after all). I'm inserting what I wrote
to John about this a couple of days ago:

----
> Re:
>> Other places with room for improvement are the interaction/event handling
>> code--too much of this resides in HandMorph. Also the event handling ought
>> to be refined--it's not good that mouseDowns are taken as clicks, for
>> example.
> 
> It could be that you are right; it has been a long time since I last
> looked at this. When you say that mouseDowns are taken as clicks, do
> you mean that many morphs treat them that way, or that there is no
> other way to handle them?

The default dragging code is in the Hand; it does this and so it applies to
all Morphs--unless you modify this, which is quite difficult since the
control is not in the Morph itself, really.

For example, the hand triggers drags on mouseDowns, before yielding control
to the receiver IIRC (it's something like that at least). This also applies
to dragging, button assignment and menus, modifier keys, etc. (Sorry if I'm
not right in the details here.)

In my view, the hand should be responsible for directing "commands" (ie.
dispatching events) from the user to objects, and the objects should be
responsible for dealing with them.

> The way it orginally worked was that the
> morph itself could decide how to handle the mouse. If it wants to,
> a morph can track the mouse and only commit to an action on the mouse
> up event. (It is even fairly easy to arrange to get click and double-click
> events in a particular morph, although it is a bit non-obvious. Fortunately,
> somone on the Squeak list documented it quite well.)

Right, you *can*, in theory at least, but it's quite hard to get away from
the stuff in HandMorph. I've implemented my own dragging, giving complete
control to the "dragee", as I really needed it for more sophisticated
interaction behavior, and boy...

For example, it's the hand that decides whether a Morph should be able to
handle an event, calculating priorities for a Morph & its submorphs instead
of delegating this, and so on. It seems backward to me, and causes a lot of
isKindOf:s.

I've subclassed HandMorph with my own class, and it consists of a
respectable number of unusually long methods (for Smalltalk--like 50 lines
rather than the five to ten usual ones), copied in their entirety from
HandMorph but where I've changed say two or three lines, the rest is
duplicated verbatim. And IIRC, most of it is for handling quite special
cases, like for PartsBin, DropShadow, Halo, and so on.

----

Henrik