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

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


Lars Clausen (| 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?

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