Hi Hans-Martin,

Hans-Martin Mosner wrote:
> Juan Vuletich schrieb:
>   
>> Hi Folks,
>>
>> The Weekly Juan #3 is out at www.jvuletich.org . Today I talk about
>> Coordinate Systems in Morphic 3.0.
>>
>> Hope you like it. Any comment is welcome, especially discussion about
>> the ideas and the design.
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>     
> Hi Juan,
> working on ideas "in the open" as you do is very refreshing!
>   
Thanks. It's nice to see your interest!
> I've got some comments on the coordinate system ideas:
> I think that you're right in giving each morph its own coordinate system
>   
Cool.
> For most GUI work (widgets etc.) however, I would prefer if these
> coordinate systems were merely translated relative to the global
> coordinate system. I fear that contemporary-style widgets don't look
> well if their graphics are scaled by more or less arbitrary factors.
> For document rendering, it is very good to have the arbitrary-scaling
> thing built in anyway, but traditional widgets should use simple
> translations by integer offsets.
>   
Well, with Windows Vista, and such I guess this will change pretty soon. 
Everybody will be crazy about vector-graphics widgets.
Anyway, I was thinking on including the behavior you describe as an 
option. Perhaps I should include NonZoomingMorph class or such to be the 
root of the hierarchy of these.
> This also means that I would rather keep the resizing operation, in
> addition to a zooming operation. Getting consistent looks for example
> for borders gets awfully complicated otherwise. 
Yes. But I think having  both operations could be confused. The 
NonZoomingMorph hierarchy should have resize but not zoom.
And perhaps a subhierarchy is not needed. It should be enough with using 
a new kind of Location and a new kind of CoordinateSystem. These morphs 
perhaps should not be rotated too.
> If you look at the way
> MVC does its transformation stuff you will see what I mean. The whole
> business of computing global from local transforms, taking border widths
> into account, it ridiculously complicated and error-prone. Believe me,
> I've tried to fix that stuff without changing the concept too much more
> than 15 years ago and failed miserably because that code is so
> convoluted... When VisualsWorks introduced the current graphics
> architecture everything was suddenly so much easier to get right. But
> the good folks at ParcPlace did not include arbitrary transformations
> (most likely due to technical constraints in the rendering systems of
> the supported platforms), and this needlessly complicates some
> applications such as zooming of documents.
>
>   
I see.
> I would like to describe the coordinate system of a morph with these
> objects:
> 1. A 2D transformation which transforms points in the morph's own
> coordinate system into points in its parent's coordinate system. The
> point 0 at 0 within its own coordinate system would be its position within
> the parent. I deliberately do not use the terms "center" since for
> different morphs it might have a different meaning. For example, for
> lines of text, the X axis of the local coordinate system would be the
> baseline. Typical X-Y diagrams would use the intersection of X and Y
> axis, while most traditional GUI widgets would probably use their upper
> left corner.
>   
I think my pair CoordinateSystem / Location allows doing this.
> 2. A rectangle in local coordinates describing the "bounds" of the
> morph. Most morphs would not draw outside of this box. Typical
> exceptions are character glyphs, morphs with graphical indicators for
> focus or defaultness (as in Motif), and of course morphs with components
> which are outside of their bounds.
>   
This are the height/width ivars in Location.
> 3. For rendering optimization and hit testing, a "total bounds"
> rectangle which encompasses all areas in which a morph and its submorphs
> could possibly render.
>   
My Morph class, as in standard Morphic, has an extra ivar for this named 
fullBounds. However, I'd be happier if I could remove it.
> 4. (Optional, maybe only needed by some morphs) a clipping area which is
> used to restrict rendering of the morph itself and especially its
> submorphs. BalloonCanvas probably does not support this well, though.
>
>   
This is a good idea.
> For working with coordinates, generalized 2D transformations are much
> more powerful than combinations of translations, scaling factors, and
> rotation angles. They can easily be composed to compute global
> transformations from local ones. One thing that must be done with
> special care is the correct transformation of line widths, patterns, etc.
>   
Note that the default behavior is to scale line widths as well.
> A first implementation using Balloon can probably be done, but some fine
> details might only be doable right with a framework such as Cairo where
> others have already put a lot of work into getting things right. Don't
> get me wrong - I'd prefer to have everything done within Squeak to be
> independent of external libraries as far as possible, but even though
> the Squeak community has a lot of really bright folks, our resources are
> ultimately limited, so doing everything ourselves is not always feasible.
>
>   
Currently I'm using Balloon. The new framework is very young yet. 
However, if at some time, I clearly see the advantage of using Cairo, it 
should be simple to switch. However note that neither Balloon nor Cairo 
fully support arbitrary transform. If the transform is non linear, I'll 
have to do the drawing by hand.
> Cheers,
> Hans-Martin
>   
Cheers,
Juan Vuletich