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!
I've got some comments on the coordinate system ideas:
I think that you're right in giving each morph its own coordinate system
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.
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. 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 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.
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.
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.
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.

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.
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.

Cheers,
Hans-Martin