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

[Dave Hoover <spamless4 iasun2 epfl ch>]

Cyrille Chepelov wrote:

> I didn't have the time to test yet, but once your patch applies to CVS, have
> a look at the Analog Clock object.... I guess we're not that far to xeyes...
>  
The major difference, is that the everything in xeyes.dia was created 
using plain old line, circle, and telephone objects, without any code. 
Each eye is a short arrow with a filled oval ending that covers the 
stem.  Moving one of the eye handles around causes the eye to jiggle 
around in the socket. The only pre-requisite is the new line object.

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.  By adding text to the box, the center has moved relative to 
the top-left corner, which is the point that determines snap-to-grid 
behavior.  Now if you move a box, the top-left point will snap to the 
grid, and your diagram won't look nearly as nice as before because the 
line is still pointing to the center, which has moved a bit since you 
added text to the box.  So a line that was vertical before, now is not 
quite vertical anymore.  And in snap-to-grid mode, it is now impossible 
to make it vertical.  Thus, when centers are used to connect objects, 
centers should be used to determine 'snap-to-grid' behavior, instead of 
the top-left point.  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.

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

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.  I think the gapped lines should have 
connection points at each end  and in the center of the VISIBLE line. 
Connection points could be added as usual using button 2.  But this led 
me to something else.  The default line object only has 1 connection 
point in the middle, and none on the ends.  This makes sense if the line 
handles are at the line endpoints.  But in the gap case, the line 
endpoints do not necessarily coincide with the line handles.  So it 
seems like it is imperative to have connection points on the visible 
ends of the line.  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?

Dave.