Re: chickenpox: dia in LWN (again)

[Cyrille Chepelov <cyrille chepelov org>]

Le Fri, Mar 19, 2004, Ã  02:50:44PM +0000, Alan Horkan a écrit:


> > Look at the filled-circle end of the brown arrows. Notice how they are
> > unaligned? Yes, we're lacking connection points in most of our objects.
> 
> He could have lined up the dots in that diagram by producing a vertical
> line and making it white/hidden and then connecting the dots along the
> connection points of that line.  It isn't great but it works.  (Which
> reminds me, connection points on the ends of lines allow us to join lines
> to lines is something I forgot to file a bug report about).

For the hidden line trick, indeed. That's just a little bit cumbersome.
For why lines don't have connection points at the end, there is a very good
reason: the connection point would hit the connector end of the same object
instance, and that doesn't give a pretty result.

> > Well, not always, sometimes we have too many of them, but here's my point:
> > we frequently end up in a scenario where we don't have an adequate number or
> > placement of connection points.
> 
> I'd certainly like to see at least a centre point automatically added to
> everything as it would make it easier to use imported SVGs and Images
> directly as reusable shapes without needing to provide additional markup
> or a shape file to wrap them in.

Hmmm. I'm not sure this is necessary. Shall we want to allow plain SVG and
images to play the role of shapes directly, such an import facility just
needs to pepper the imported shape with static connection points, including
one in the centre.

> > Enter "chickenpox-mode", the thing I'd like to implement. In a nutshell,
> > this would be the ability to dynamically create connection points anywhere
> > within an object (or shape -- anything here would apply to the base
> > classe(s)) instance when one finds the existing CP's are inadequate, and
> > later delete them (when they're no longer useful).
> 
> I'm wondering if perhaps you have considered making this
> available/representing it as an extra special layer?

I haven't considered it. What I had in mind was to make dismissed CPs appear
"deleted" while the implementation would be to simply hide them.
 
> > I think from the UI point of view, it needs to be close to the "snap to
> > grid" switch; except that it should be a three-way switch:
> > 	1. No dynamic CP creation (current behaviour, default)
> 
> > 	2. Add CP on edges (this, in effect, would snap on the intersection
> 
> If this is the same as "Snap to Objects" *(lines and objects snap to the
> circumferance/outline of an object) would be great as it allows you to do
> nice things like snap a hexagon right beside another hexagon or snap
> images beside each other and made crude jigsaws or quickly draw tiled
> drawings.

It's much more difficult. Snapping a point to an arbitrary shape's edges is
an interesting problem, but mating two arbitrary shapes is a hell of a can
of worms (though... I can see a use for that. A special move mode where
Elements are required to not collide with each other, and would not obey
mouse drags where such a collision would happen. Using the actual object
shape, of course, bounding boxes are for cheaters).


> > A menu entry "remove all unused connection points" (which will actually hide
> > unused old-style CPs) will complete the design.
> 
> I would think that when you save would be a good time to purge any orphan
> connection points but depening on how you do it you will probably need to
> have this functionality somewhere else.
> This all soonds a little complex to stick in the menus, and adding a Panel
> to preferences might not be a bad idea depending on configurable you
> make the system.

I'm not yet too sure what would be best. It's really to clean up an object
once one has created a bunch of CPs by dumping connector objects to it.

> > Finally, to ease the transition, ConnPoint_Line will become effectively
> > dead-wood code, as I don't see who would want to use this style of dynamic
> > CP addition-removal anymore, but I'm afraid we won't be able to get rid of
> 
> The nice thing about the connection points at the moment is that they are
> evenly spaced on the line, I'm not sure it would be easy to layout
> things as neatly in this one specific ase with the new dynamic system you
> propose.  It isn't very important but I thought it worth mentioning that
> the current system does have at least some nice points.

This is a very good point indeed. CPL is useful the way it is, and needs to
stay (and play nice along with chickenpox). 
 

> > Now, the questions:
> > 	1. Does this make any sense from a user interface and user
> > expectation point of view?
> 
> I hope I've given you some idea of my user expectation.
> You really should try Visio as that is what a lot of user expectations
> will be based on but I'm sure you can do something better than what I've
> seen.

I have a little problem, I don't have access to Visio. But that's clean-room
reverse engineering, not a big deal, eh? :-)
 
> > Does this solve a real problem, and does it
> > appear to solve it in a desirable way?
> 
> I believe it does, I think you have the fundamentals right.

Thanks.

On an implementation point of view, I have a little more details to add:
	- ConnectionPoint will grow two new fields. One will be the CP's ID
number (initially, and for the transition phase, this ID will be equal to
the CP's index in the Object::connections array, but eventually this won't
hold anymore). The second field will be the connection point's coordinates
in the object's logical space, U-V (more on this below).

	- Object will gain two new virtual methods. One will convert an
object's CP's position from logical to geometric coordinates; the second
will do the opposite.

	- for Elements, the logical space is U=0..1,V=0..1, where 0,0 is the
top-left corner and 1,1 is the bottom-right corner (simple X = U * elem->width,
Y = V * elem->height).
	- for Connections, only U is used, and is in the 0..1 range. U=0 =
at the first endpoint, U=1 = at the second endpoint, U=.5 = in the middle
	- for poly_conn, V is used as the segment number, and U is 0..1
within the segment (yes, this ain't euclidian). Or maybe V is ignored, and U
in 0..1 means first segment, 1..2 second segment, etc.
	- this scales nicely to Beziers and polybeziers
	- I'm less enthusiastic for polyshapes, but I'm sure someone will
figure it out before I start coding. Maybe something simple based on a
composition on the first two segments? Or, following the alternate space for
poly_conn, V is not ignored and describes which segment to use as the second
generator and the displacement relative to it. Anyway.

The goal of this mess is so that when a poly_conn or a poly_bezier is
resized or bent, the dynamic connection point moves to where the user wants
it to (for Elements, it's rather trivial, and even if only this case is
solved initially, it'll already bring about a bunch of benefits).

We'll need a couple of routines to get the closest point of a line, of a
bezier, of an arc, to a given point. The intersection(s) between a segment and
a segment, bezier or arc (and beziers to segment, bezier, arc, you get the
idea -- yuck). Given a point X-Y assumed to be on a bezier, what's the
coordinate in Bezier parametric space.

With that in hand, it's just GUI implementation afterwards ;-)

> This sounds like it would be good post 0.93 and before 1.0 (whenever that
> might be) but I wouldn't presume to know what Lars has in mind.

With what I wrote just above, it's clearer to me now that this really is
post .93 material. I have enough to chew on with the intersections stuff
already... then the index->identifier transition for accessing the
Object::connections array. Generous valgrinding, deliberate fudging of
CP indices and reloading older diagrams to make sure I didn't get anything 
wrong. Then only the actually interesting stuff. Huh, a real lot of stuff to
do indeed :-)
 
> Hope my comments and suggestions are of some use.

They sure are; thanks a lot!

	-- Cyrille

--