Re: gEDA-user: Snap-to-pins, was: Stupid newbie question

[Ales Hvezda <ahvezda@moria.seul.org>]

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