Re: Feature freeze

[Dave Hoover <spamless4 iasun2 epfl ch>]

Lars Clausen wrote:

> > For polyline, it will be simple.  calculate_gap_endpoints and
> > calculate_object_edge will work.
> >    
>
> What happens if the gap is greater than the end segment?
Good point.  If we used calculate_gap_endpoints, the a funny thing would 
protrude in the
wrong direction at the corner.  Code will have to be completely 
different, but it would still
be relatively simple, I think.

0.  Make sure (absolute_start_gap+relative_start_gap/polyline_length) + 
(...end_gap...) <= polyline_length.  If not, erase line (?).
1.  Set gap := remaining_gap.
2.  Look at the end segment, if it is shorter than 'remaining gap', 
throw out segment,  subtract segment length from remaining_gap, and 
repeat step 2.
3.  remove 'remaining_gap' units of length from end segment.

....

I am now working on bondgraph objects.  Thanks, Lars, for creating the 
directory.  Got the make stuff figured out.  I would like to make a bond 
object that I can use for BG modeling.

bond.c would be similar to line.c.  It would turn red if it's not 
connected to two appropriate 'ports'.  It would have flat arrow heads, 
half-flat,
half-heads, full heads, optional center/end/start labels, and so on. 
Question:

Can I make this into a test bed for modular arrow code?  Could we either 
indicate to
users through some obvious title that the object may change in the 
future, or could we make it so that the object would only appear if a 
certain ./configure option is given?  I would like it to be easy for 
other mtt developers to use this code, as well as dia developers.  At 
the same time, the arrow stuff will maybe change over time, breaking old 
diagrams.  Does it really matter, since if somebody is playing with CVS, 
they know that things are bound to break.  What do you think?

I don't imagine that you want me sending you weird diffs for line.c on a 
regular basis...

Dave.