[DISCUSSION] Hidden and Open: O'Keefe as "everyman"

Bill Spight bspight at pacbell.net
Thu Feb 13 17:19:35 UTC 2003


Progris Riport:

I wrote:
> That sounds like what I did. Just to make sure, I tried again. I made a
> new RectangleMorph, opened a viewer on it, and dragged out the script.
> Then I made a new GoMorph, opened a viewer on it, got its tile, and
> dropped in on the script. 
> 
> Maybe my problem yesterday was not dropping it on the Rectangle tile. I
> dropped it right on there. Nothing happened to the script, except it had
> the Go tile sitting on in. No matter where I dropped, no effect.
> 
> What's wrong?

After a couple of more emails from Ned Konz, I tried again. As he
suggested, an empty script (^ self) is not enough. This time I made the
script, 'Rectangle hide', then dropped the Go tile over the Rectangle
tile, and made the replacement. So far so good.

I am doing this because I want to send a message to the GoMorph that I
see no way to do with the tiles available. So I switch the script to
written form and replace 'hide' with 'board: 5 at 5'. I am telling the Go
morph to change the size of its board to 5 by 5. To my surpise (having
tried something like this before) the script is accepted. Now to run it.

Oops! Debug time. 'Message not understood'. The message, OC, is 'board:
5 at 5'. The object that does not understand it is Player51. Well, that's
not surprising. Why should it understand? And it's not too surprising,
but a bit dismaying, that all is not what it seems. Wheels within
wheels.

However, this whole excursion was in response to Andreas's notes
stating:

> The point was usability and
> efficiency.

> Don't you realize that the Morphic that is perfect for
> eToys *is* the one that is perfect for programmers?
> 

> To me, this is the logical result of many of the shortcomings of Smalltalk.
> For example, subclassing for using the framework.

> Given this, any attempt to "clean up" Morphic is doomed to fail if it does
> not address the "usability issues" for the programmer. The best you can hope
> for is a temporary effect but any newbie can (and therefore will!) write
> code that breaks the framework. Some of this code will either be cool or
> needed enough so that someone else is going to use it and you'll end up
> exactly where we are right now. 
> 
> Documentation, tests, etc. will (while being useful) not solve this problem.

> Bridging this gap, making the "system
> level" part of Squeak more like eToys is the thing that needs to be done. In
> particular in the UI area since that's what most people will look at and
> play with first, so it's the place where strong fences are most needed
> (present in eToys).

I would love to work within the framework (whatever that is, exactly). I
like Morphic, it's why I'm here. :-)

But I need instance variables of types not among the 9 that are not
quite obviously available for scripting. I need more functionality (at
least, I think I do). I need better communication with Morphs than I
have seen. (It's probably available, but where?)

I'm a newbie, I made some Morphic subclasses, I broke the framework. So
sue me. Did I want to do that? No. Is Smalltalk the problem? Not for me.
Without it how could I have gone oven the fence to get done what needed
to be done? Is documentation or the lack thereof a problem? Not so much
for some people, but definitely for me.

I have a functioning GoBoardMorph (subclass), and a GoMorph (another
subclass) that is not fully functional yet, but it's getting there. Are
you cool with what I have done and am doing? Fine. No problem. If not,
and there seem to be those who are not, then help me out. I'm perfectly
willing to redo everything. Is that too much time and trouble? (It would
be for me.) OK, give me some good documentation. Is that too much time
and trouble? If so, what can I say?

Thanks for listening,

Bill



More information about the Squeak-dev mailing list