Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005202 [Squeak] Morphic major N/A 10-08-06 21:30 10-10-06 05:42
Reporter rhawley View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version 3.9
Summary 0005202: Appropriate relay of messages from the morph to its costume (+ derivative improvements)
Description Currently the following does not work (when reasonably it should):
   EllipseMorph new openInWorld; lowerPen; turn: 135; forward: 500
The first fix given in the attached changes file fixes this by relaying messages to the morph's player.

This is a major fix that will make it much easier to drive morphs using direct Smalltalk code - a bonus for the initial teaching of Smalltalk. (It makes coding consistent with using the EToys scripting tiles).

The second fix in the attached file allows morphs to be accessed using their names. E.g. :
  (World morphNamed: #Star) forward: 99
This is useful for the "Press Me" button - this fix is used to allow the name to be specified in the Target field of a button.
Additional Information Morphic scripts can send messages like forward: to Morphs, but currently, if this is done as Smalltalk code it does not always work because the morph needs to relay the command to its costume, but if the costume does not yet exist it will need to be explicitely created. The separation of 'player' and 'costume' means that a morph cannot currently directly respond to player messages; as the trick of trapping the doesNotUnderstand: is already being used for morphic's tile based scripts, it seems reasonable to use the same type of technique so that we can write code that properly treats morphs as first class objects (as they were intended to be).

So, with this fix we can straight forwardly do things like:

X := EllipseMorph new.
X openInWorld.
X lowerPen; turn: 135; forward: 500

Testing: An example Morph that makes very good use of the relaying works well. The main effect is to ensure that the morph's player exists, so the scripting system is not effected by this change.

Second Matter

The naming of Morphs is currently not fully developed or very convenient to use. The fix to the SimpleButtonMorph makes it possible to reference a morph by using:
(World morphNamed: #Jim) forward: 99
assuming that you have bought up the halos and edited a morph's name to be Jim. (This also makes use of the first fix to relay the forward: message.)

Testing: This has worked with several examples. The fix tests for flaps so that it can ignore them - because flaps of the same name as a morph are created. If there is more than one morph of the same name, it is essentially arbitary as to which gets chosen. There may be possible future improvements, but the fix works as intended so far.
Attached Files  MorphMessageFix.1.cs [^] (3,734 bytes) 10-08-06 21:30

- Relationships

- Notes
(0007630 - 1200 - 1314 - 1314 - 1314 - 1314 - 1314)
10-09-06 02:31

Hi rhawley,

This sounds interesting and I can understand your motivation for doing it.

I notice this is done on top of 3.8. (6665)

Several things have happened since then.

In 3.9 I wrote code to allow buttons to retarget. You select sight target. Move the James-Bond target site over the morph you wish to select.
You get a menu of ALL the morphs under the cursor. Select the one you wish to be the target and its done. Works for scroll bars too.

I started to look over your code. What would it do if you ask for an non-existant name? What would happen if you asked the world to move forward 99?

The other uneasiness is that your extention will increase the surfaces area and interconnectedness of morphs in that all will have to know about pens and etoys and what not. This is not so good a structure from the point of view of maintenence. Think about what package your code would need to belong to.

I have an open mind about your idea. I ask that you try 3.9 and the target sighting features with an open mind also. See if it informs your thinking.

Then thnk about issues of integration and packaging.

At that point it would be worth communicating some more.
(0007633 - 897 - 979 - 979 - 979 - 979 - 979)
10-09-06 04:36

Answer to wiz: I like the 'James Bond' targeting in 3.9. The 'naming' modification given here would be another feature that need not conflict with that. I will come back to that in the future.

However, my primary fix is the relay of messages to the player. This fix only creates a player for the morph if necessary (no unrequested interconnectedness). It is a simple fix implemented in the Morph-Kernel doesNotUnderstand: method.

It seems eminently natural to be able to do things like:
  EllipseMorph new openInWorld; lowerPen; turn: 135; forward: 500
Can this be taken forward more quickly than the other issue?


Other answers: I tried relaying to the world and it didn't do anything obviously wrong. I had installed and tested the code in 3.9 without problems. This 'primary fix' does not do anything different from what the tile-scripting already does.
(0007640 - 699 - 783 - 783 - 783 - 783 - 783)
10-10-06 05:42

Hi Bob,

Thanks for your reply.

I'll think about it more in light of what you have said.

I'm not an etoy expert so this is the first time I been exposed the DNU trap for fixing things. Need to ponder.

What we really need is some use testing. (Not just for your stuff).

And please think on where this might be packaged. I am concerned with the detangling of morphic so that it can be easily maintained. (And I look at everything with my suspicious eye first.)

As for the behavior your proposing it seems a natural extention of what one would expect morphs to understand. And the more I looked at your code the more I saw that you took effort to cover all the bases.

Cheers, --Jer

- Issue History
Date Modified Username Field Change
10-08-06 21:30 rhawley New Issue
10-08-06 21:30 rhawley File Added: MorphMessageFix.1.cs
10-09-06 02:31 wiz Note Added: 0007630
10-09-06 04:36 rhawley Note Added: 0007633
10-10-06 05:42 wiz Note Added: 0007640

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
42 total queries executed.
31 unique queries executed.
Powered by Mantis Bugtracker