Re: Waiting for a call, xeyes, and vector fields

[Lars Clausen <lrclause cs uiuc edu>]

On Wed, 27 Nov 2002, Dave Hoover wrote:
> Lars Clausen wrote:
> 
>>After playing around with it a bit, I'm thinking there are more uses than
>>just the bond graph stuff (and of course the coolness of all those
>>arrows...:) For instance, if you want an explanatory label pointing to
>>something, it's better to have it stop a little before the something.
>>And for things like text objects, we could have a connection point in the
>>middle and not have to worry about the line overlapping (once we have the
>>distance thing).
>>
> That's what I've been thinking.  Thus, my
> 'make-center-connection-points-on-all-objects' obsession.  But there's
> a snap-to-grid hitch: If you add a connection point to the center of a
> flowchart/box object, neatly connect a bunch of these boxes using
> their center points, and then you put text inside each box, you will
> have a problem.
[...]
> Or 'snap-to-grid' could have
> an option specifying whether the top-left of an object should
> snap-to-grid, or the center should snap-to-grid.  Perhaps you think
> this is crazy, but when you mess around with center-pointed lines for
> a while, for objects that can change size, you run into the problem
> right away.

We already have this problem with the corner cps.  If you connect to the
right corner and expand the object, your line goes off-vertical.

>>Cool little demo.  Can I put it on the webpage for the next version?
>>
> Of course.  But before this stuff is made really public, there are a
> couple things that maybe should be addressed:
> 
> 1.    I think the new line should get an official name that is not
> going to change.  I made the suggestion that the new line be in a
> 'Geometry' library in one of my e-mails, since 'gaps are not just for
> bond-graphs anymore'.  I now agree fully that it should not be the
> default line.  If someday defaults/properties dialog boxes are
> reconfigured to have 'advanced' options, then it might be feasible to
> replace the default line with this code, once issue 2 is dealt with...

Actually, I have an idea to make a multi-prop widget that's collapsible.
That would neatly take care of such cluttering, and then it'd be ok to have
it on the standard line.

> 2.    In the xeyes demo, you probably noticed the funny connection
> points floating around by themselves.  These connection points are
> half-way between the line handles, even if the lines are drawn
> somewhere else due of the gap parameters.  
[...]

It should be in the middle of the displayed area.  Fixing that in CVS.

> But what happens when all gaps are
> zero?  In this case, the connection points will coincide with the
> handles.  Will this screw anything up?  It seems like it shouldn't,
> since the box object has connection points that coincide with the
> handles.  Since connection points may change in the future for this
> new line object, either they should be disabled completely, or they
> should be fixed to coincide with the VISIBLE line (maybe requiring
> changes to connpoint_line.c), or a simple static connection point
> configuration should be made with start/center/end of visible line
> connections.  What do you think?

Same thing would happen if you make a zero-length line regardless of gap.
The analogy to box isn't good, as those are different kinds of handles
(non-connectible).

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