gEDA-dev: Re: gEDA: Complex place list

[Carlos Nieves Ónega]

Hi Werner,

El dom, 18-06-2006 a las 18:25 +0200, Werner Hoch escribió:
[snip]
> > The complex place list is a list of objects, without any other
> > struct:
> >
> > struct st_object {
> >   /* Lot of hidden variables */
> >   OBJECT *prev;
> >   OBJECT *next;
> > }
> >
> > When placing new components, they are just linked in the complex
> > place list.
> > If we want to use them for component actions, we need to link the
> > selected objects using the prev and next pointers of the object
> > struct, thus changing the complex order in the main object list. This
> > is a problem because when moving the selection (for example), the
> > selected objects have to be removed from the main object list and
> > placed into the complex place list (and there are other things to
> > take into account when unlinking objects from the main object list).
> 
> Why? The selection can still remain in the main object list. Unlinking 
> the original selection is something I'd do after the move/copy/place 
> action finished.

I'd want to use the selection list as a list of pointers to objects in
the main list. I can't do it with the current structures because the
object data is mixed with the prev and next pointers (the list is
embedded into the data).

> > I think the easiest solution here is to convert the complex place
> > list into a doubly-linked list, possibly using glib's GList lists.
> > This way an object list can be built without changing the main object
> > list.
> 
> If I understand you correctly you're still working with the original 
> objects, not with a copy of the selected objects?

Yes.

> I think the "working selection" should contain a copy of the selected 
> objects. No matter which container (GList or the st_selection) is used.

Why? Actions where the object doesn't need to be copied are more (move,
rotate, place) than those which needs to copy the object (only the
"copy" action, I think).

> > When moving the selection, instead of moving the components from the
> > main list to the complex place list, the complex place list could be
> > a list of pointers to the objects of the main list, and o_redraw*
> > changed so they don't redraw the selected components at the original
> > position if gschem is inside a move/rotate/.. command.
> 
> This will require to track any user operation as you don't have objects 
> that you can rotate/move/mirror/... 

The selection list is there. It can contain objects or pointers to
objects in the main list. If it is inside a copy command, the selection
list will contain objects (copied objects). If not, it only contain
pointers to objects in the main list.
Thus, the position and rotation of the objects in the selection list is
updated when you move it on the screen, so the redraw function only has
to redraw all the objects in the selection list and/or the main list. It
doesn't need to worry about wether to draw or not the objects at the
original position.
  
> And now something completly different.
> We're currently doing lot's of undraw/redraw action of selected 
> elements.
> Could we modify the drawing code so that we can tell which action to do 
> on the selected objects:
> * regular draw (e.g. when in copying mode
> * rubberband draw (e.g. when in selection mode)
> * don't draw (e.g. when in moving mode)

I'd love to simplify the drawing code. At least for me, it's a mess
right now. Maybe if using a single redraw function with a new parameter
(what to do with the selection)?
Another thing to do....

Regards,

Carlos