Hi Chad,
[snip]
>Since the SHIFT key is not checked as a modifier during net drawing, what I've
>done is integrated a check just below where the CONTROL key is looked for.
>That way the snap behavior is optional. I have an iterator doing what you
>described in your other e-mail message, basically just looking through every
>object and checking its endpoints if it's an OBJ_PIN. It also "drills into"
>OBJ_COMPLEX types looking for pins, although I wasn't sure if this was really
>important.
Yes, actually going into the complex object is very important
as that is where all the pin objects really exist.
>
>As I got into the structs and found where they were defined, everything
>started making a lot of sense. I used to do a lot of MUD development and
>having thousands of linked lists of structs all over the place is second
>nature to me. I've got a bug in it right now that's not finding the right
If you haven't noticed already, there are two particular points about the
code:
1) Yes, there are linked lists everywhere, but unfortunately, due to the
organic nature of the code, linked lists are implemented in at least
two different ways. First is a home grown implementation which I wrote
in the very beginning and second, extensive use of glib's GList.
2) This noweb thing. noweb is/was an experiment in literate programming.
Please feel free to submit patches to me against either the noweb
files or .c files. For now noweb would be easier, but I can deal
with .c patches as well.
>endpoint coordinates but when I get it fixed I'll let everybody know, then you
>can show me the "right" way Ales.
>
I'll cut right to the chase then. A tile is nothing more than a
fixed size subdivision of the entire world space. The entire world space
is divided into a 10 x 10 grid. Each grid space is a tile.
When you add a net/pin/bus to the schematic, libgeda keeps track
of which tiles the object lives in. This done via two data structures:
1) w_current->page_current->world_tiles[][] is an array of TILE
structs. Each TILE struct holds a GList of all objects contained
inside the tile as well as the bounding box of the tile.
2) o_current->tile_locs is a GList of TILE_LOC structures. Each
object (nets/pins/buses) knows exactly which tile it belongs to.
Here's a very rough (just off the top of my head, so might not work)
outline of how to walk through pins/buses/nets using the tile mechanism.
1) Figure out what tile your mouse pointer is currently in.
Convert screen mouse coords into world coords
Divide the x and y coords by the size of a single tile.
Resulting x,y pair is the tile array index.
2) Figure out what tiles are surrounding you.
6 | 7 | 8
--+---+--
3 | 4 | 5
--+---+--
0 | 1 | 2
Suppose your mouse pointer is currently in tile 4, then you
would probably have to search tiles 0 through 8 looking for
nearest pin/bus/net neighbors. This really just boils down
to visiting neighbors in an array and handling the boundary
conditions.
3) For all surrounding tiles, look into the world_tile array to
find the list of objects to consider.
It's not too bad to traverse using the tiles, but it is a little bit
more complicated then just traversing the object list.
-Ales
