A cleaner Morphic for 3.5 (was: Re: Re-doing Morphic ( Was: Re:Traits prototype image ))

Daniel Vainsencher danielv at netvision.net.il
Tue Feb 11 22:34:08 UTC 2003

Hi Andreas.

Andreas Raab <andreas.raab at gmx.de> wrote:
> Daniel,
> > we could use this kind of
> > refactoring to separate the "Morphic" programmers use to build boring
> > old applications, from the "Morphic" that's perfect for eToys.
> Nothing personal, but as of now, this is the most frustating message I have
> seen in this thread. Don't you realize that the Morphic that is perfect for
> eToys *is* the one that is perfect for programmers?
I'm not taking it personally, I can see you feel very strongly about
this. And maybe you're right. A few years ago I was trying to convince a
bunch of users the wonderful application we were writing for them was
exactly what they needed, if only they'd change the way they work
somewhat. They never understood it and the project was never used by
more than a bunch of people. I've experienced very few more frustrating
things in my life. To this day I know I'm right, but I also understand
now that that was a result of a failure to communicate. 

These days, I'm willing to walk a pretty mile to communicate well enough
the things I care about.

So first I'd like to understand what you're saying. Especially since
you're the Morphic expert here.
> I'll give you just one example: If I want to make a button in eToys, here is
> what I do. I go to the supplies flap, grab a rectangle, open its viewer,
> drag out the "color <- <...>" tile, set the color I want, set the trigger to
> "mouse down", grab a second "color <- <...>" tile, change it to "mouse up"
> and done.

So what you're saying is that all of us should be working (creating
applications and such) using direct manipulation of morphs, instead of
writing those annoying openAsMorph methods, right?

You do realize that if I want to share my code, I'll want to place it in
SM, and I don't know how to serialize this nice morph I've created, with
it's scripts, and the rest of my package, into one nice SAR. I can make
a project, and put that up, but I won't really know what exactly it
decides to put in there, and I don't know how to do version management
(comparison of two versions) for projects. Are there solutions to this

Further more, since I might want to create such morphs in code (for
example, generating either morph/MVC from a spec), specifying a way of
creating it manually doesn't cut it. I need it to be programmable. To be
programmable, it has to be understandable. To be understandable, the
framework can't be dependent on it's own users, and every technology
they happen to use. Therefore, some core needs to be separated from the
rest of it. Are you trying to say that that there is a part of eToys
that needs to also be in the core of the base Morphic, because it
provide a usable API that is better in this way? Great! can you explain
what it is, so that we move that into the depedency clean Morphic?

I'll stop speculating here, since it's quite likely I was wrong
somewhere along the line, please point out where.

> If I want to make the same button using your "programmer's morphic" here is
> what I needed to do: Go to the tools flap, open a browser, make a category
> "My stuff" (never mind that I might have no idea where to go next after
> opening the browser), figure out the thing I have to subclass (nevermind
> that I might have never heard of Morph or RectangleMorph or whatever else),
> define my class. Then I need to know what exactly this method is called that
> I have to write - it's #mouseDown: (nevermind that I have no interest
> whatsoever in the event which is passed along), then I need to write
> something like:
> 	self color: (Color r: 0.67 g: 0.43 b: 0.95).
> (nevermind that I have to know these numbers, nevermind that I have to know
> that I must not assign to the instance variable even though it happily
> allows me to), then I implement a similar method for mouseUp:, then I need
> to remember that this isn't enough - oh no, I still need #handlesMouseDown:
> (as if the system couldn't figure out for itself). Now I have a class where
> I have no idea whether it'll work or not. So then I open up a work space, go
> in there type "MyButtonMorph new openInWorld" (nevermind that I have to
> remember that weird message) and then I can finally see if I have made a
> mistake or not.
> So which way would you rather use yourself?! Unless someone has a really
> masochistic inclination I can safely claim that the first one is the way to
> go - it's better in every single way, starting from the ability to use
> direct manipulation, over robustness, up to efficiency (even I need about
> five times as long with the second one and I know *exactly* what I'm doing).
Well, that you Andreas. I don't know what I'm doing when I'm doing
Morphic GUI code. But I copy paste from here and there, and I get it
done in time X. If I took the direct manipulation route, I would have to
go to a tutorial (since you can't read or copy paste direct
manipulations) and hope they are doing what I need, because I don't
really know where to look if they don't. But the most frustrating thing
is that when I'm done I have no idea what to do with my creation.

This is not sarcastic - it's my experience report. I'm sure I'd have
more success if I had an experienced eToys person next to me, but that's
not the case.

> And this is exactly what I said in my message (and what frustrates me so
> about what you write) - if anything we need *MORE* eToy-like things in
> Squeak and and in particular at the system level. 
Here's where I don't even kid myself that I understand what you're
getting at. Please, be explicit. *What* eToy like thing? reflection
based interaction in the programming environment? autogenerated
anonymous classes hidden in the background? I really don't know what
part of eToys (or what related idea) you think is the missing
ingredient. And it really feels like you have something specific in mind
- if so, please, spit it out! :-)

> What you are proposing is
> not just one, it's two steps backwards.
I'm sure it looks that way from where you're standing. And maybe you're
right, too. But understand that it doesn't to me, nor to a bunch of
other people, and that matters.

What I see in what I'm saying is that we can keep everything functioning
as we know how to use it, without breaking eToys, just moving it gently
into a subclass, where we don't have to look at it (and everything it's
dependent on) too often. And yes, to me, right now, that sounds like a
good thing. 

Hopefully, in less than 10 more messages, I'll see your point of view,
or you mine...

Daniel Vainsencher

More information about the Squeak-dev mailing list