[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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.
So far, I haven't run into this issue, but thanks for letting me know, I'll keep my eyes open.

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.
Uhhh, yeah, I sort of wondered about that but didn't want to ask. =) I've yet to meet anybody that raved about literate programming's benefits after a multi-developer Open Source application was well underway. I'm not a fan myself, either, but I'm also not trying to change the world, just get one feature implemented. I've been writing the code on the .c side to reduce the steps in the try-compile-test-shoot that didn't work-trythis-compile-test cycle with plans to convert it to the .nw side when I was ready to submit, but if you can tolerate a .c patch that's fine by me!

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.
Wow, that's JUST what I was looking for to optimize the search routine. The only complexity is what you'd have with any tile-based system - if you're near the edge of a tile sometimes you have to search two (or four if near a corner). Not a big deal.

How big are the tiles? I'm only searching within a certain number of pixels of the pointer's current location, so unless the tiles are very small I would probably only need to search 2-4 of them. My hope is to come up with a smooth way of searching within 1/3rd of the distance between pins (based on the design guide pin spacing suggestions) so if you're close to two pins you get the one you really want. I tried snap_distance/3 but that's not working too well at the moment. I'll have to experiment with it.

Also, do you mind me adding a function to the o_net namespace? I'm implementing most of this in a find-closest-pin function since it's occurred to me that it might be useful for other developers down the road. It would be easy to abstract this to specify the type of neighbor you're searching for. There are all sorts of uses for this. For example, it would be easy to use it to make a feature that allows you to hold SHIFT while dragging a pin and snap the non-connection endpoint to a rectangle's edge if within a certain distance. That way you could drag pins around the edge of a symbol and they would "follow" the edge. (I have arthritis and I'm always searching for keyboard shortcuts that can reduce my mouse work, especially in close-positioning tasks.)

Regards,
Chad