Re: Waiting for a call, xeyes, and vector fields
- From: Dave Hoover <spamless4 iasun2 epfl ch>
- To: dia-list gnome org
- Subject: Re: Waiting for a call, xeyes, and vector fields
- Date: Wed, 27 Nov 2002 11:17:04 +0100
Cyrille Chepelov wrote:
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.
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...
Lars Clausen wrote:
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.
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
Of course. But before this stuff is made really public, there are a
couple things that maybe should be addressed:
Cool little demo. Can I put it on the webpage for the next version?
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?
] [Thread Prev