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

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]