[PythonCAD] pythoncad points

[Eric Wilhelm]

# The following was supposedly scribed by
# Art Haas
# on Tuesday 27 July 2004 01:17 pm:

>> If I draw a circle, and then a segment which uses the circle's center as
>> one end, saving this drawing results in a point table with two entries. 
>> This implies that the entities are associated to the same point (e.g.
>> dependent on each other.)
>
>Yes, because they segment endpoint is the same as the circle center.
>
>> But, if I move the circle or move the segment, saving results in a point
>> table with three entries.  This implies that the entities are independent.
>
>They are now independent because neither of the segment endpoints falls
>on the circle center.

Okay, so you are saying that they are associated unless they are not ;-)

This is a valid theme iff it carries through into the interface.  Resolving 
this will give the coherency that I'm looking for.  Right now, it seems that 
the dependence only really manifests itself in the file-format and 
data-structures (and thus is capable of also manifesting itself on-screen in 
the form of bugs.)

>I just took a look at the move code in 'Generic/move.py'. The
>'move_objects' function is called when a boxed selection is called. It
>omits the case when a point is included in the boxing, and that looks
>like the root cause of this discrepancy. Adding a bit of code to this
>function to retrieve all the entities associated with a point and move
>them whether or not they were within the boxed region would not be a big
>deal I believe.

It would have to go slightly beyond that.  I'll see if I can hammer this out 
below...

>> There is validity to both approaches, but if you aren't making pythoncad
>> into an associative program, I think associating common points is
>> inconsistent with that design philosophy and capable of opening several
>> corner cases that you wouldn't have if you simply treat each entity as
>> self-contained.
>>
>> I think it comes down to this:  Do the entities own the points or the
>> points own the entities?  If the points own the entities and are capable
>> of owning more than one entity, the interface would eventually need to
>> support editing points as such and orphaning entities (giving them a new
>> parent point.)
>
>When trying to answer this, I want to say that "entities control points"
>and I also want to say "points control entities", so I need to sit and
>figure out when "entities control points" is more true than "points
>control entities", and visa-versa.

Okay, so pythoncad is to be an informally associative drafting program.  
That's great.  Now to just make it have a coherent data/interface theme.

Let me try this analogy:  My father is MY father, but he is also my brother's 
father.  We are both HIS children.  Let's say my brother and I both live at 
home.  What happens when my father relocates is fairly clear.  Without 
getting overly legal or emotional, what we have to decide is what happens 
when I emancipate myself and what happens when my father orphan's me.  In 
either case, I become my own guardian.

Translating this to the point and circle, I've got to be two entities when I 
lose my parent (or rather, I will create a parent for myself.)

So, in creating a circle where there is no point to snap to, a 'parent' point 
must be created which controls the center of the circle.  The circle has a 
cp="0" attribute which proclaims that it is owned by the point with id="0".

If I create a segment, with one as-yet-unused point and the point "0", the 
first point of the segment is again a parent which springs into existence.  
The second point of the segment is an existing parent, which adopts the 
segment. (now we have two points and two entities (one shared point.))

If I move the circle, it is no longer owned by the original point.  Rather, it 
must find (or create) a new parent point.

If I move the line, both of its parent points are possibly left without 
children.  The line will have two different parent points after the move.

If I move the point instead of the circle, I am simply moving the point.  This 
causes a deformation of the segment.

AutoCAD handles a procedure similar to this with its 'grip-edit' 
functionality, where you select one or more entities and drag a point.  Any 
of the selected entities which have that point in common are modified.

But, this is not autocad, and here the points are associative in-memory and 
on-screen, so let me try my hand at a list of rules.

1.  Creating Entities:
  A.  no existing points:  new points are created and 
    used to 'parent' the entity
  B.  existing points:  the point parents the entity

2.  Moving Entities:
  A.  Shared point:  new parent point(s) is(are) created 
    for the moved entity.
  B.  Not shared:  new parent point(s) is(are) created, 
    old parent point is deleted.

3.  Moving points:
  A.  all entities connected AND selected:  move the 
    point, allowing entities to follow
  B.  some entities connected AND selected:  move 
    the point, allowing selected entities to follow, 
    create a new parent point at the old location to own 
    the un-selected entities.

Note that:
  2B implies that points never move when entities are selected, rather the 
destination points are created anew (and source points are destroyed if 
unused)
  2B combined with 3B implies a special selection method for moving points 
where points are selected first, and then entities.  This could default to 
select all connected entities, and de-select mode could then be activated.
  This also implies the need for more feedback as to what is selected 
(highlighting of points and entities.)
  A global points table should be used, so that entities can share the points 
across layers.

This is just one possible theme, but (IMO) if you don't have this or something 
like it, the points are NOT associated (e.g. redundant points are saved in 
the file, points are not selectable,  and coincidence of two points is only 
coincidental:)

--Eric
-- 
Cult: A small, unpopular religion.
Religion: A large, popular cult.
                                        -- Unknown