[NEWBIE] Good Morphic Design, communication
ned at bike-nomad.com
Tue Jan 7 23:54:00 UTC 2003
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.
> 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
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
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.
GPG key ID: BEEA7EFE
More information about the Squeak-dev