gEDA-dev: Fwd: Re: gEDA: Complex place list

[Werner Hoch <werner_dot_ho-at-NOSPAMgmx_dot_de>]

The message didn't arrieve at the mailing list, next try ;-)

----------  Forwarded Message  ----------

Subject: Re: gEDA: Complex place list
Date: Sunday 18 June 2006 18:25
From: Werner Hoch <werner.ho@gmx.de>
To: geda-dev@seul.org

Hi Carlos,

On Saturday 10 June 2006 00:50, Carlos Nieves Ónega wrote:
> Hi all,
> I'm thinking about how to use the complex place list for component
> placement and object moving, copying, rotating and so on...
>
> Currently, the selection list is a doubly-linked list of selected
> objects. The selection struct is:
>
> struct st_selection {
>   OBJECT *selected_object;
>
>   SELECTION *prev;
>   SELECTION *next;
> };
> (aside thought: why don't use a glib's GList here?)
>
> 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 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?

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

> 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/...


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)

regards
Werner

-------------------------------------------------------
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev