Hey Arcadie,
It's great to hear from you, thanks for the review, more below...
On Sat, 2011-10-01 at 00:48 +0300, Arcadie Cracan wrote:
I don't follow the reason of introducing the ConnPointChild type, but I guess it is my fault as the code is not that much verbose.
Your code uses ConnPointUserDefined and ConnPointDefault as a way of defining not only where the nodes would go but also how the lines would be drawn once you created a connector point.
I'm using ConnPointChild to tell the knot creator to draw an X rather than a square knot for the user to click on. That's all. I could be using it to switch on the parent group signal handle, but I figured it was just better to switch that on for all groups.
The main idea was to have two types of connection points: some default connection points (as currently only the center is) and user defined connection points.
I think there is a conceptual error in your design for this functionality. Your model has only two parties: programmers and users. Programmers make code which automatically computationally offers presets for generic objects i.e. center, users define arbitrary and use once creations which are specific to that creative work.
The third set of people missing are the templators. People who create objects similar to what you can see in the video, they don't want the computational stuff in their way as it's too ridged and they certainly don't want arbitrary and error prone mouse inputs. If templators have to edit the svg directly in order to produce the stencils and templates required for productive use in inkscape, they can and then ship them out to users.
with the concept of a third way safely understood we can see how simply having the ability to insert arbitrary points is insufficient, you also need to be able to move them in relation to the creation. I made a lot of use of align and distribute functionality to get my points into the correct locations and I imagine it would be a dis-pleasurable experience trying to click on a specific pixel or move it with the keyboard.
There would be 9 default connection points: the center (the only one available now) and other 8 connection points that you get when you draw 8 imaginary lines that connect the center to the corners of the object's bounding box and the midpoints of the edges of the object's bounding box and intersect these imaginary lines with the object's edge.
Some objects will not want those extra 8 points, the start/end flowchart objects for instance should not have them for fear of confusing new students in the art of flowcharting.
which one would compute the intersections I mentioned above.
It's possible that we should have computational points, but they should be defined by the shape's dynamics. Triangles should have 7 points, hexagons 13, etc. Moving the computational work out of detection of bounding boxes and into the shape code would make it cleaner and clearer how it works.
one should have to add the knots for the rest of the default connection points.
Fairly easy, but data should come from the item about which points to use.
Thank you again for the great work!
Let me know when you're finished with your PhD work, it'd be nice to work with you on this. also please do continue to talk with me about the idea. I'm on IRC if that helps.
Martin,