🚀 go-pugleaf

>i) Can someone out there list the RULES FOR USING TRANSFORMERS
>   (the Transformations processor) in InterViews. Browsing through
>   the literature and the man pages, I drew a blank. Stepping through
>   some code and dumping out data structure values unravelled part of
>   the mystery, but is turning out to be an extremely tedious
>   process.

You can review the matrix representation with any good graphics
textbooks, but the following may help clear up some confusion:

1) Assuming a Graphics instance hierarchy A-B-C-D with A being the
root and D being the leaf.  The corresponding Transformer hierarchy is
Ta-Tb-Tc-Td.

2) The effective Transformer for D is Td*Tc*Tb*Ta.  i.e.

        Td->postmultiply(Tc);
        Td->postmultiply(Tb);
        Td->postmultiply(Ta);

3) The previous approach changes Td, which is undesirable.  More
commonly, one would write:

        Transformer t;
        D->TotalTransformation(t);

4) Graphics are typically displayed through a GraphicBlock.  The
origin of the Graphics is relative to the lower left of the canvas of
the GraphicBlock.

5) Now for instance, if one wants to position D's center to (50.0, 50.0),
the following code would fail:

        float x, y;
        D->GetCenter(x, y);
        D->Translate(50.0-x, 50.0-y);

Instead, one should take into account intermediate transformers:

        Transformer t;
        float x, y;
        float dx, dy;

        D->GetCenter(x, y);
        dx = 50.0;
        dy = 50.0;
        C->TotalTransformation(t);  // or D->Parent()->TotalTransformation(t);
        t.inverse_transform(x, y);
        t.inverse_transform(dx, dy);
        D->Translate(dx-x, dy-y);
        

>ii) Can I abstract the graphic state representation of InterViews to
>    a normalized and succinct representation in terms of a
>
>	- a chosen number of fonts, brushes and a perspective, and
>
>	- co-oridnates with respect to an absolute frame of reference
>
>    With this normailized representation I want to recreate a replica of
>    the graphic (same scaling, translation, rotation and perspective)

In the previous example, the effective graphic state that D uses to
draw is the concatenation of A, B, C and D's with A's most dominant.
You can normalize A by creating a helper function that recursively
calls Bequeath (flushing graphic state and transformer to children) on
A B ...  In this case, you can use

        float x, y;
        D->GetCenter(x, y);
        D->Translate(50.0-x, 50.0-y);

to locate D since intermediate tranformers are nil.  However,
normalizing graphics is dangerous in Unidraw applications since a lot
of the undo operations rely on intermediate nodes remembering their gs.

>iii) I am having trouble with initializing the HANDLER for a component
>     derived from GraphicComp. This is the sequence of operations 
>     I perform 
>
>	- obtain the original coordinates of the views graphic, 
>
>	- apply the graphic's total transformation to these
>	  coordinates
>
>	- initialize a rubberhandle with the transformed co-ordinates
>
>    This does not work! What I get are rubber handles that are translated
>    to the left and to the bottom and these *do not change* when the graphic
>    is zoomed into.

Rubberbands are initialized with window coordinates.  So if you just
get the center of the view's graphic (which is relative to the
Viewer's canvas), your rubberband should be initialized correctly.


Steve