Kuba,
> There are seeming inconsistencies in cycle copying between types.
>
> Following types have the cycle list:
>
> - label
> - polygon
> - spline
> - arc
>
> Only polycopy() and splinecopy() call copycycles().
>
> Is that intentional, or is a copycycles() call missing from labelcopy() and
> arccopy()?
Cycles maintain information about the points selected for editing. I
call them "cycles" because for polygons, splines, and arcs, one cycles
through the points in sequence when editing.
The incosistencies are intentional. One can select specific collections
of points from a polygon or spline to edit, where the edit is a separate
command. The selected points need to be saved on the undo stack in between.
By contrast, there is no way (at least, I didn't define one) to select
and edit a portion of an arc, so no selected point lists are saved.
Arc editing goes through a specific cycle as well (radius, 1st endpoint,
2nd endpoint, ellipse minor axis), but it always goes through the same
cycle. So the arc has the cycle variable, but it does not need to be
copied, since arc editing is an immediate action that has no "undo"
record associated with it.
Labels are a different case. I decided it would be much better to replace
the variables areawin->textpos and areawin->textend with the label->cycle
variable. However, the label editing code works, and I haven't felt a
particular urge to change it. I think as the code exists now, you could
remove the cycle variable from the label record and it would not be missed.
To explain it another way:
The multiple-element editing in xcircuit 3.7 lets you grab, say, the right
side of a group of different polygons, splines, and paths; and stretch them
further to the right. For that, it is necessary to maintain the cycle
records of all the polygons, splines, and paths. I find this feature very
useful when I've just written out a table, and discover that I need more
space in one of the columns. Drawing tables was a pain in xcircuit prior
to 3.7, even though tables are pretty common in schematics (logic tables,
title blocks, etc.). On the other hand, if you grab a bunch of elements
to stretch to the right, as I was using for an example, arcs and labels
are not going to be split or stretched, but just picked up and moved if
they are within the selection area, and ignored if not (arcs that are
joined into paths are converted into splines, which may be a bit of a
hack solution, but I find it easier to deal with, myself). Consequently,
I save groups of edit points for polygons and splines, but not for arcs
and labels.
> NB1: Some splinecopy() and polycopy() calls are followed by a redundant
> copycycles()
> -- that's a memory leak since copcycycles() does not attempt to free anything.
Okay, thanks for pointing this out.
> NB2: Some arccopy() calls are followed by copycycles(), but not all.
> None labelcopy() calls are followed by copycycles().
There is a sort of simplified "undo" mechanism for arcs/splines/polygons/
paths that existed before "undo" and probably would have simplified the
code a bit if I had converted it to the "undo" code. Like "undo", the
state of the current arc/spline/polygon/path being edited is pushed onto
a stack. In this case, one does make a copy of the "cycle" variable for
the arc. That explains why arcs only call copycycles() when pushing and
popping the edit stack. Labels, as I mentioned above, never have anything
but a NULL value for cycle.
> PS. Have you ever ran xcircuit through Valgrind's memcheck?
No, I haven't, although I occasionally run programs linked to the
TCL_MEM_DEBUG version of Tcl/Tk. I don't really know how the two methods
compare for efficacy. I guess the Tcl memdebug is better for detecting
out-of-bounds array access; it allows one to check for what memory has
not been freed when the program exits. However, if you depend on the
OS to free a bunch of allocated memory on exit, then it isn't much help
in finding ongoing memory leaks.
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| Open Circuit Design, Inc. | web: http://opencircuitdesign.com |
| 22815 Timber Creek Lane | phone: (301) 528-5030 |
| Clarksburg, MD 20871-4001 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
