Re: Interesting interactions between objects and renderers

[Lars Clausen <lrclause cs uiuc edu>]

On Wed, 03 Apr 2002, Ben Hetland wrote:
> If it may be of any help... or trigger some new ideas...
>
> Lars Clausen wrote on 24 Mar 2002 18:56:35 -0600:
> > When a line gets an arrow at the end, the endpoint of the line should be
> > moved backwards at least to the backside of the arrow, possibly to the
> > backside of the stem, if such is used.  I did this in the renderer, and
> > it worked well.  There were some problems with it though:
>
> My first thoughts given your general descriptions of the problems (and
> earlier discussions) were taking me in the direction of applying a
> Decorator pattern to this problem. In that case, all this "arrow
> related" logic would go into a special (preferrably generic) Arrow
> Decorator which would also be responsible for any endpoint translations,
> mouse click & bb coordinate transformations, etc...
>
> The renderer interface might require some adaptions to support this
> paradigm though, considering especially...
> > 3) We can't just move the actual endpoint of the line, as some renderers
> >    (xfig, pstricks?) will want to render the line as 'line with arrow'
> >    rather than 'line' and 'arrowhead'.  They would want to know the
> >    original points.

I notice that the function that checks if you click on an object is
independent of the renderer, and calls distance_from() in the object.  So
if the objects knows that it's been adjusted for arrowhead, it can account
for that.  

If we made a Decorator, it would have to know about the internal structure
of the object it decorates, in particular the layout of points (which is
tricky sometimes, see the Arc object).

Assume that we make the arrows that adjust lines (somehow, decorator or
change in object or something).  The mouse click routines and most
renderers will use the adjusted points, while some renderers that know
arrows can use the original points.  We must also consider the load-save
routines.  Unless we make a version change for each object and add some
code to fix old objects, the save routine should use the original points.
Two very separate places need the original points.

> But IIRC, you Lars -- or was it Cyrille? -- also had an idea earlier of
> making "overridable methods" in the renderer in such a way that the
> "default" (base method) would do things the hard way, doing everything
> itself, while concrete renderers could override and implement the
> advanced functions (like "arrow with arrowheads" and "bezier") if their
> target would support that directly.

Yes, it is already implemented, though nothing uses it yet.  I made it
exactly because I wanted to fix the arrows, but more problems came up (as
always). 

A default implementation for draw_line_with_arrow would get either the
original or the adjusted points.  If it gets the original, it will have to
adjust them before it can render with the primitives.  If it gets the
adjusted points, it will be fine, but any overriding renderer function
would have to deadjust the points.

> > Any ideas are welcome!
>
> Just some quick thoughts, you're problably more into the details and its
> specific problems here than I am right now, Lars.

Any thought on the problem is appreciated.

> BTW, as Cyrille Chepelov wrote on Mon, 25 Mar 2002 07:42:56 +0100:
> > aware of the transforms the objects is applying onto itself -- I really
> > can see this going as a generic layer over the existing routines, for
> > the general case of whole-object transforms.
>
> ...which is also along the ways of the Decorator idea, more or less,
> isn't it?

Hmmm... not sure.  I don't speak Patternse very well:)

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?