While all of you are thinking about this, you should also see what 
Knuth does in TEX using "glue" which is a kind of spring .... and 
"dynamic programming" to pull all together .... Ian Piumarta is 
rumored to have a TEX solver in Smalltalk somewhere ...

Cheers,

Alan

------
At 7:52 PM -0700 5/17/01, Ned Konz wrote:
>On Thursday 17 May 2001 19:47, Mark A. Schwenk wrote:
>>  At 5/17/2001 07:33 PM, Ned Konz wrote:
>>  >Can someone suggest where Cassowary might be useful for the kinds of
>>  > drawings I've been dealing with (i.e. shapes connected with lines)?
>>
>>  How about automatically positioning the shapes, using the lines as springs.
>>  You can read an object instance model from the system, generate
>>  collaboration diagrams showing the object relationships with the layout
>>  done by the constraint engine. And then if you wanted, you could turn off
>>  the constraint engine (at least in localized areas) and tweak the diagram a
>>  bit.
>>
>>  It could also be used in laying out network diagrams, organization charts,
>>  parse trees, etc.
>
>You know, I've thought about this a bit, and it seems like it could be done
>without having to use a constraint system.
>
>I imagine a process that can be run on demand to re-position shapes based on
>their interconnections. Push a button, and things are rearranged (with,
>perhaps, a property that could exempt certain shapes from being rearranged).
>
>Attaching a single ConstraintMorph to each of the movable shapes that
>examines the connections and re-positions its constrained object would do the
>trick. You could either leave the CM attached, or delete them after they've
>done their job. Every step time the CM would examine the connections to its
>constrained shape, and compute a vector that it would use to move its
>constrained shape.
>
>This would occasionally lead to oscillations, but you could manually move an
>oscillating shape to fix it.
>
>I can't imagine a simultaneous solution for _all_ the shapes in a big
>drawing; you'd almost have to compute them separately anyway. In which case
>you have got the simple case: a bunch of independent variables (the
>connections looked at as springs) and one dependent variable (the resultant
>vector for this step). And this doesn't require (or benefit from) a
>constraint solver.
>
>Unless I'm just not seeing the benefit.
>
>--
>Ned Konz
>currently: Stanwood, WA
>email:     ned at bike-nomad.com
>homepage:  http://bike-nomad.com