Thanks for your work on these changesets!  I will try them out.  In the
meantime, I tried a couple of strategies myself to solve the original
problem of finding free space on the screen to popup a message.  The
first one was:

"do a binary search starting with the world area and
 recursively splitting the area in 2.  a choice between the 2
 halves is made by calculating the area of the half minus the area of
all
 morphs contained or intersecting it and then choosing the
 larger of the 2.  the search stops when either the entire area
 of a half is smaller than the object we are trying to place (negative
result)
 or the area contains no other morphs (positive result). woohoo!"

This was lots of fun, but didn't really work very well because
splitting the area in half each time throws out a lot of useable area. 
The second strategy was more successful, but kind of flakey:

"pick a random position in the world (minus the width and height of the
morph being placed).  if none of the other morphs in the world
intersect a morph-sized Rectangle at that position, then return that
position (positive result). if something intersects, try again up to
100 times.  if we go past 100 tries then return the default position
(negative result)."

Obviously as the screen gets more cluttered, it will take more tries to
find an open spot.  I also searched the Web and came up with a paper
describing a method of finding the maximum tool size to cut a specific
pattern on a programmed milling machine (an obvious real-world
application of this idea?).  It was written as a professional journal
article, and I didn't understand a word of it, unfortunately.

On Tuesday 26 November 2002 11:36 am, Ned Konz wrote:
>On Monday 25 November 2002 10:22 am, Anthony Hannan wrote:
>> from preamble:
>>
>> Send 'layoutPolicy: AdjacencyLayout new' to any Morph to make its
>> submorphs never overlap.  Have a submorph return false to the
>> 'beAdjacent' message if it should ignore this no overlap rule.
>
>Interesting, but be warned that this CS will break Connectors, as it
>conflicts with a change to Morph (the one change to the base image
>made by Connectors). (Morph>>addedOrRemovedSubmorph:). The change
>that Connectors makes could be used by this CS, though.
>
>Even after fixing that conflict, it doesn't work too well with
>Connectors. I suspect that some morphs will have to return false to
>beAdjacent (like the connectors themselves, and the highlight 
>morphs, which are right now not special Morphs).



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com