[NEWBIE] Good Morphic Design, communication

Bill Spight bspight at pacbell.net
Thu Jan 9 23:27:50 UTC 2003


Dear Ned,

Thanks again for your help, on more than one occasion. :-)

I have studied your response and the classes you mention, and have come
up with the following design idea. The board (or its submorphs) when
clicked, do not know the meaning of the click nor what they are
interacting with. Even so, I think it's a good idea to use #on:send:to:
or #on:send:to:withValue: , sending the selector to a GoBoard handler,
which is an instance variable of the GoBoard. There will be a default
handler, for when the GoBoard stands alone, and any object that wants to
interact with the board replaces the handler for the duration of the
interaction, restoring the previous handler afterwards. I think that's a
fairly clean design that will handle the potential complexity.

Many thanks!

Bill

--------------------------------------------------------------------

Ned Konz wrote:
> 
> On Tuesday 07 January 2003 10:04 am, Bill Spight wrote:
> 
> > Here is what I am doing. I have a fairly dumb GoBoardMorph. I want
> > to use it not just for Go, but for GoMoku, Gonnect, Clobber, and
> > other games; also for displaying game-related information by
> > mark-up. So it will interact with various other objects and users.
> > I suppose that there are various ways of doing this, but what is
> > good Morphic design?
> 
> You can define an event handling scheme in an enclosing object (look
> at PasteUpMorph for examples). This would let you have a consistent
> strategy for dealing with input events.
> 
> A simple strategy might be just to make everything but the board
> itself locked. That way the board will get all the user interaction.
> 
> It can then relay that information to the model (the game itself).
> 
> > Some objects will basically tell the BoardMorph what to do; for
> > instance, a Reader that reads game records and replays them. It
> > this case I think that making the Board an instance variable of the
> > object or a subMorph will work just fine.
> 
> Sounds good.
> 
> > In other cases the user will be playing a game, composing or
> > solving a problem, making a diagram, etc. The meaning of mouse
> > events, the messages sent back and forth, and the objects
> > interacted with will depend on the circumstances. In thinking about
> > all this it seems to me that the board should stay pretty dumb and
> > the interacting objects should handle most of the work. In fact,
> > should the board even know who it is communicating with? Shouldn't
> > the Hand act as gobetween, sending info and queries from the board
> > to the interested object and vice versa? Is that good Morphic
> > design?
> 
> The hand shouldn't know anything about the board other than that it's
> a morph. When the board gets events (or the objects on it do,
> depending on your strategy) it can contact the model for the actual
> meaning.
> 
> Look at MorphicEventDispatcher and the Morph message category "event
> handling" for the following (I could have some of the details wrong):
> 
> The hand goes to the World first for event handling; the World then
> decides what to do with the event. The default event handler goes
> down through the ownership hierarchy from parent to innermost child
> to find a morph that wants the event. At any point you can provide a
> new event handler, or handle the event.
> 
> You can have the Hand grab morphs, drop them, etc.; you can change the
> Cursor shape if you have modal interactions.
> 
> > Another question about using the Hand: At one point there may be
> > the Board, on top of that a Point, on top of that a Stone, on top
> > of that a String on Mark. Say that the Hand, above them all, wants
> > to communicate with only one of them. I guess that it uses
> > #mouseFocus: to select which one it will communicate with. But how
> > does it know what Morphs are beneath it?
> 
> You can query what Morphs are below a certain point (by asking a
> parent morph, perhaps your board or the world).
> 
> If all but the board are locked, all the input events would go to the
> board. Otherwise you'd have to make it so that the input events went
> to the correct morph. By default, the events will get sent to the
> topmost (or is it innermost?) Morph that wants that kind of event,
> but this strategy is pluggable via the EventHandler.
> 
> --
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE



More information about the Squeak-dev mailing list