Andreas Raab <squeak-dev at lists.squeakfoundation.org> said:
>Just for the records: To me, this is a fundamentally broken model when it
>comes to the distinction between the UI elements and the objects themselves.
>IOW, when we have a (potentially scaled) object and want to provide
>(unscaled) UI elements we need to distinguish between the object and its
>editor. Which could mean that (for example) we have some "polygon editor
>morph" which _contains_ a (scaled) polygon as well as (unscaled) handles.
>
Thanks. Yes, that makes sense. 

>An interesting statement given that (in light of the following) we're really
>talking about one or two classes. What's the problem with "junking the lot
>of" PolygonMorph and do a clean-room implementation? You got plenty of code
>to look at how things are done and not limited by any of the existing stuff.
>
Yeah, that's my conceptual blockage, probably - there's a lot of code in
PolygonMorph which all goes into the bin when I subclass Morph directly
for my own polygon behavior. Of course, I can copy'n'paste, but being a
house-trained object guy I try to avoid that at all cost ;-).

>Which (given your requirements) may actually spare you a lot of time down
>the road. I think it's a good idea for your project to implement it from
>scratch.
>
Yeah, I have come to that conclusion as well. We will be adding a lot of
algebraic stuff to our design objects (if you have read Alexander's
works, try to envision programmatically doing something like 'positive
space'), so I'll probably separate Model and Presentation at this point
as well to make it completely flexible.



-- 
Cees de Groot               http://www.tric.nl     <cg at tric.nl>
tric, the new way           helpdesk/ticketing software, VoIP/CTI, 
                            web applications, custom development